Dyskutując wczoraj m.in. z apsem o pewnym kawałku kodu natrafiliśmy na ciekawą (moim zdaniem) różnicę w implementacjach funkcji atoi, [sf]canf %i oraz strtol (z której btw w niektórych implementacjach korzystają [sf]scanf oraz atoi) między msvcrt (Microsoft C-Runtime Library), glibc (GNU C Library), a libc używanym na OSX.

Różnica dotyczy konwersji string->int liczb które wykraczają poza zasięg zmiennej, tj. są większe niż INT_MAX (0x7fffffff = 2147483647), lub mniejsze niż INT_MIN (0x80000000 = -2147483648). Przykładowo:
printf("%.8x\n", atoi("12345678901234567890"));
printf("%.8x\n", atoi("-12345678901234567890"));
Powyższy kod wygeneruje następujące wyniki:

* msvcrt (do wersji msvcr71 włącznie)
eb1f0ad2
14e0f52e

* msvcrt (od wersji msvcr80 włącznie)
7fffffff
80000000

* glibc
7fffffff
80000000

Czyli, jak widać powyżej, w przypadku starszych msvcrt następuje overflow, czyli to co widzimy w wyniku to 32 dolne bity większej liczby; natomiast w przypadku glibc oraz najnowszych msvcrt mamy do czynienia z saturacją, czyli konwertowana liczba nasyca się po osiągnięciu wartości granicznej (INT_MAX lub INT_MIN).

Żeby było zabawniej, zachowanie to bywa różne dla różnych funkcji (atoi/sscanf %i/strtol).

Anyway, zrobiłem kilka testów tych trzech funkcji (dla liczb podanych w przykładowym kodzie) na różnych wersjach MS C-Runtime Lib i GNU C Library, oraz na OSX, i wyniki wyszły ciekawe (szczególnie na OSX):

name	arch	ver	atoi-	atoi+	sscanf-	sscanf+	strtol-	strtol+
crtdll.dll	32-bit	?	OF	OF	OF	OF	Sat.	Sat.
msvcrt.dll	32-bit	7.0.7600.16385	OF	OF	OF	OF	Sat.	Sat.
msvcrt.dll	32-bit	7.0.3790.3959	OF	OF	OF	OF	Sat.	Sat.
msvcrt20.dll	32-bit	2.12.0.0	OF	OF	OF	OF	Sat.	Sat.
msvcrt40.dll	32-bit	6.1.7600.16385	OF	OF	OF	OF	Sat.	Sat.
msvcr71.dll	32-bit	7.10.3052.4	OF	OF	OF	OF	Sat.	Sat.
msvcr80.dll	32-bit	8.0.50727.4053	Sat.	Sat.	OF	OF	Sat.	Sat.
msvcr90.dll	32-bit	9.0.30729.1	Sat.	Sat.	OF	OF	Sat.	Sat.
msvcr100.dll	32-bit	10.0.30319.1	Sat.	Sat.	OF	OF	Sat.	Sat.
GNU Lib. C	32-bit	2.7	Sat.	Sat.	Sat.	Sat.	Sat.	Sat.
GNU Lib. C	32-bit	2.7-10	Sat.	Sat.	Sat.	Sat.	Sat.	Sat.
GNU Lib. C	32-bit	2.11.1	Sat.	Sat.	Sat.	Sat.	Sat.	Sat.
GNU Lib. C	64-bit	2.9	-1	0	-1	0	-1	0
GNU Lib. C	64-bit	2.11.1	-1	0	-1	0	-1	0
GNU Lib. C	64-bit	2.11.2	-1	0	-1	0	-1	0
OSX ? Lib. C	64-bit	OSX 10.6.4	-1	0	-1	0	-1	0
OSX ? Lib. C	32-bit	OSX 10.5.8	Sat.	Sat.	-1	0	Sat.	Sat.

Podziękowania dla Zarula Shahrina oraz Unavoweda za wykonanie testów na OSX'ach.
Update: Podziękowania za wyniki oraz uwagi dla: djstrong, przemoc, ppkt, Rolek, faramir
Update: W tabeli, na 64-bitowych systemach, wynik funkcji strtol jest zrzutowany na int

Musze przyznać, że zwrócone w kilku przypadkach wyniki na OSX (-1 oraz 0) są pewnym zaskoczeniem dla mnie i jestem ciekaw z czego wynikają (jak mi się uda sprawdzić, to będzie update do postu).
Update: W przypadku 64-bitowych systemów i strtol zrzutowanej na int oraz funkcji polegających na strtol zwracane jest (kolejno) -1 oraz 0. Dzieję się tak ponieważ strtol zwraca (jak słusznie Unavowed oraz przemoc zauważyli) long int, który na 32-bitowych systemach ma 32-bity, a na 64-bitowych ma 64-bity, a więc strtol zwraca (kolejno) 0x7fffffffffffffff oraz 0x8000000000000000, które po przycięciu do 32-bitów dają (kolejno) 0xffffffff oraz 0x00000000, czyli -1 oraz 0.

Natomiast nie tłumaczy to specyficznego zachowania %i w sscanf na 32-bitowym OSX (być może pojawi się więc kolejny update).
Update 3: (ponowne podziękowania dla Zarula) Sprawa się wyjaśniła: sscanf w OSX korzysta wewnętrznie z funkcji strtoimax która zwraca intmax_t, który jest zdefiniowany na x86 jako int64_t, czyli po prostu long long. Więc konwersja jest wykonywana na 64-bitach z saturacją, a następnie zwracane są dolne 32-bity, czyli -1 lub 0.

Warto byłoby jeszcze sprawdzić czy za każdym razem w przypadku saturacji następuje ustawienie zmiennej globalnej errno na ERANGE (patrz cytaty ze standardu c99 do strtol poniżej).

Update oraz Update 2:
W komentarzu poniżej Rolek wrzucił wyniki powyższego testu również dla funkcji atoi/atol/wtoi/wtol (dla liczb 1234567890123456789012345678901234567890 oraz -1234567890123456789012345678901234567890). Jak się okazało, w przypadku crtdll.dll (wersja ?) oraz msvcrt20.dll (wersja ?) wyniki dla testowych liczb (oczywiście w przypadku wto[il] podanych w wersji wide/unicode) są zaskakująco różne od zwróconych przez ato[il]:

* crtdll.dll oraz msvcrt20.dll
atoi 0xCE3F0AD2 0x31C0F52E (OF)
atol 0xCE3F0AD2 0x31C0F52E (OF)
wtoi 0xEB1F0AD2 0x82167EEB (truncate(20) → OF)
wtol 0xEB1F0AD2 0x82167EEB (truncate(20) → OF)

Skąd ta różnica? Jak się okazuje, autorzy wto[li] w tychże wersjach poszli na łatwiznę robiąc z wto[li] wrapper na atol, który zajmuje się również konwersją wide-char→ascii (za pomocą funkcji WideCharToMultiByte z limitem wielkości ustawionym na 20 znaków (czyli max 20 cyfr w przypadku liczb dodatnich, oraz max 19 cyfr w przypadku liczb ujemnych, z uwagi na znak minus).

W nowszych wersjach bibliotek wto[li] zaimplementowane jest jako normalna funkcja (a nie konwertujący wrapper), oraz posiada wsparcie dla cyfr reprezentowanych nie tylko tak jak w ASCII (U+0030 do U+003A), ale również dla około połowy innych znaków którymi w 16-bit unicode można zapisać cyfrę (np. U+0660 do U+066A aka Arabic Digits, czy U+FF10 do U+FF1A aka Full Width Digit).

printf("%i\n", _wtoi(L"\uFF11\u0663\u0C69\u17e7")); → 1337

"\uFF11\u0663\u0C69\u17e7" to oczywiście １٣౩៧

By the way...
On 22nd Nov'24 we're running a webinar called "CVEs of SSH" – it's free, but requires sign up: https://hexarcana.ch/workshops/cves-of-ssh (Dan from HexArcana is the speaker).

OK, na koniec kilka cytatów ze standardu C99:

atoi
The functions atof, atoi, atol, and atoll need not affect the value of the integer
expression errno on an error. If the value of the result cannot be represented, the
behavior is undefined.
sscanf %i
Nie znalazłem wzmianki o takiej sytuacji, a jedynie pewne sugestie (nie wyrażone wprost), że ma się zachowywać podobnie do strtod. Czyli UB.

strtol
If the correct value
is outside the range of representable values, LONG_MIN, LONG_MAX, LLONG_MIN,
LLONG_MAX, ULONG_MAX, or ULLONG_MAX is returned (according to the return type
and sign of the value, if any), and the value of the macro ERANGE is stored in errno.
OK, i tyle na dziś :)

P.S. Hmmm, wie ktoś może jak sprawdzić wersję lib C na OSX?

P.S.2. Gdyby ktoś chciał odpalić test na jakiejś innej wersji/implementacji standardowej biblioteki C, to podaje kod (a wyniki, razem z wersją lib c oraz system operacyjnym (łącznie z tym czy jest on 32- czy 64-bitowy) chętnie przyjmę w komentarzach ;>):
#include<stdio.h>
#include<stdlib.h>

int main(void)
{
 puts("atoi");
 printf("  %.8x\n", atoi("12345678901234567890"));
 printf("  %.8x\n", atoi("-12345678901234567890"));

 printf("sscanf %%i\n");
 { int res = 0; sscanf("12345678901234567890", "%i", &res); printf("  %.8x\n", res); }
 { int res = 0; sscanf("-12345678901234567890", "%i", &res); printf("  %.8x\n", res); }

 printf("strtol\n");
 printf("  %.8x\n", strtol("12345678901234567890", NULL, 10));
 printf("  %.8x\n", strtol("-12345678901234567890", NULL, 10));

 return 0;
}


P.S.3. Zachęcam do przejrzenia dodatkowych testów i programów testujących umieszczonych w komentarzach przez czytelników :)