[trelixmorelix]

Cześć! Skontaktowałem się z Andreasem, który pracował w Oracle'u między innymi przy kompilatorze javac. Miałem pewną zagwozdkę:

byte a = Byte.MAXVALUE + 1;
int b = Integer.MAXVALUE +1;

Obie linie stanowią overflow. Pierwsza linia powoduje błąd kompilacji, a druga nie. Andreas napisał, że spędził cały dzień nad tym i owocem tego jest artykuł na jego blogu: https://programming.guide/java/int-may-overflow-byte-may-not.html

Poruszyłem ten temat, bo sam zacząłem pisać post o literałach w Javie, w tym o braku literału byte w Javie (o czym jak się okazało Andreas też już pisał).

Jeśli chcesz przeczytać o jednostkach leksykalnych, literałach, o stałych compile-time, o compile-time constant expression oraz o assignment context, to zapraszam:

https://wprostychslowach.pl/2020/03/09/literaly-w-javie/

Wyjaśnienia powyższej zagwozdki oparte są na mailach z Andreasem oraz na jego artykule.

#java #programowanie #naukaprogramowania #wprostychslowach

[menelaosPL]

@trelixmorelix: co do

int intOverflow = Integer.MAXVALUE+1 // compiles!

jeżeli mamy overflow w int, to następną wartością jest Integer.MINVALUE, takie zabezpieczenie

prawdziwy jest taki warunek (Integer.MAXVALUE + 1 == Integer.MINVALUE)

[menelaosPL]

imo lepsze by bylo wywalwnie bledu przy kompilacji

[trelixmorelix]

@menelaosPL: ano właśnie. Tym bardziej, że kompilator to potrafi w ramach assignment context. Może hen dawno temu nie było to możliwe i tak już zostało.

[matips]

@trelixmorelix:

Nie rozgryziona pozostaje kwestia int overflow:

int intOverflow = Integer.MAXVALUE+1 // compiles!

Overflow normalnym zachowaniem integera odpowiadającym temu jak procesory zwykle sobie radzą z dodawaniem. Wiele algorytmów - np. hasujących wykorzystuje ten fakt i nie ma powodu by domyślnie, defensywnie sprawdzać czy doszło do przepełnienia.

Jeśli wyjdziemy z tego założenia, to "Integer.MAXVALUE+1" jest intem (0x80000000) i można go bez problemu przypisać do innego inta.

Z kolei dla byte