Tvoj kod sadrži previše pretpostavki. Naime, ISO C standard definiše da se prilikom pojave prekoračenja (ono što ti koristiš za određivanje granica opsega celih brojeva) svaka implementacija može odlučiti da različito reaguje. Može izbaciti signal, zamku (trap) i slično. Prema tome, mada ti koristiš ponašanje koje je uobičajeno na ,,našim'' računarima i njima odgovarajućim kompajlerima, takav program neće biti ISO C kompatibilan.
Dalje, kako je veličina svake promenljive, kao i njene osobine utvrđena i poznata i u vreme kompajliranja, jasno je da će tada vrednosti date u INT_MAX, INT_MIN, FLT_MIN... biti odgovarajuće, i nema potrebe za ovakvim ,,trikovima''.
Uostalom, ovako nešto je moguće izvesti i za fp vrednosti, samo moraš posebno ,,napipavati'' granicu za svaku od zasebnih promenljivih u jednoj fp: eksponent, broj značajnih cifara, binarnih naravno, itd.
Drugi pristup ovom problemu je preko upotrebe prekoračenja za brojeve u pokretnom zarezu. Neke implementacije ISO C-a mogu errno postaviti na EDOM ili ERANGE u zavisnosti od toga da li je domen neodgovarajući, ili je vrednost prevelika za opseg vrednosti.
Još bolja varijanta je upotreba ,,floating-point environment <fenv.h>'' (v. ISO C99 7.6). Konkretno, možeš onda koristiti:
Code:
if (fetestexcepts(FE_OVERFLOW)) završi()
Na ovaj način sam uspeo da saznam opseg eksponenta (<2^128), kao i da stignem dovoljno blizu FLT_MAX. Naravno, moji testovi su bili samo približni i na brzinu sklepani, a krenuo sam od a=1, i množio sa 2 (zbog zapisa brojeva). Kao uporedni primer, dobio sam 170141183460469231731687303715884105728.000000 a FLT_MAX je bio 340282346638528859811704183484516925440.000000. Ovo delimično liči na dvostruko manji broj, ali nešto u mojoj ,,logici'' nije valjalo, pa nije bilo moguće dobiti tačnu vrednost. Međutim, ovo su sve ,,trikovi'' i nikakvih garancija nema.
Toliko. .
Ona ima definisanu relaciju