Dlaczego printf („% f”, 0); dać niezdefiniowane zachowanie?

Wyrok

printf("%f\n",0.0f);

drukuje 0.

Jednak oświadczenie

printf("%f\n",0);

wypisuje losowe wartości.

Zdaję sobie sprawę, że przejawiam jakieś niezdefiniowane zachowanie, ale nie potrafię dokładnie określić dlaczego.

Wartość zmiennoprzecinkowa, w której wszystkie bity są równe 0, jest nadal ważna i floatma wartość 0.
floati intmają ten sam rozmiar na moim komputerze (jeśli to nawet ma znaczenie).

Dlaczego użycie literału liczby całkowitej zamiast literału zmiennoprzecinkowego printfpowoduje takie zachowanie?

PS to samo zachowanie można zobaczyć, jeśli używam

int i = 0;
printf("%f\n", i);

"%f"Format wymaga argumentu typu double. Dajesz mu argument typu int. Dlatego zachowanie jest nieokreślone.

Standard nie gwarantuje, że wszystkie bity-zero są poprawną reprezentacją 0.0(chociaż często tak jest) lub jakiejkolwiek doublewartości, inti doublemają ten sam rozmiar (pamiętaj, że doublenie float), lub nawet jeśli są takie same size, że są przekazywane jako argumenty do funkcji wariadycznej w ten sam sposób.

Może się zdarzyć, że „zadziała” w Twoim systemie. To najgorszy możliwy objaw niezdefiniowanego zachowania, ponieważ utrudnia zdiagnozowanie błędu.

N1570 7.21.6.1 akapit 9:

... Jeśli którykolwiek argument nie jest prawidłowym typem dla odpowiedniej specyfikacji konwersji, zachowanie jest niezdefiniowane.

Argumenty typu floatsą promowane double, dlatego printf("%f\n",0.0f)działa. Argumenty typów całkowitych węższe niż intsą promowane do intlub do unsigned int. Niniejsze zasady promocji (określone w N1570 6.5.2.2 paragraf 6) nie pomagają w przypadku printf("%f\n", 0).

Zwróć uwagę, że jeśli przekazujesz stałą 0do niezmiennej funkcji, która oczekuje doubleargumentu, zachowanie jest dobrze zdefiniowane, zakładając, że prototyp funkcji jest widoczny. Na przykład sqrt(0)(po #include <math.h>) niejawnie konwertuje argument 0z intna double- ponieważ kompilator może zobaczyć na podstawie deklaracji sqrt, że oczekuje doubleargumentu. Nie ma takich informacji dla printf. Funkcje zróżnicowane, takie jak, printfsą specjalne i wymagają większej uwagi podczas pisania do nich wywołań.

Po pierwsze, jak poruszył w kilku innych odpowiedzi, ale nie, moim zdaniem, wypisanym wystarczająco jasno: to robi pracę, aby zapewnić całkowitą w większości kontekstów gdzie funkcja biblioteki zajmuje doublelub floatargument. Kompilator automatycznie wstawi konwersję. Na przykład, sqrt(0)jest dobrze zdefiniowany i będzie się zachowywał dokładnie tak sqrt((double)0), jak i to samo dotyczy każdego innego wyrażenia typu całkowitego tam użytego.

printfjest inny. Jest inaczej, ponieważ wymaga zmiennej liczby argumentów. Jego prototypem funkcji jest

extern int printf(const char *fmt, ...);

Dlatego kiedy piszesz

printf(message, 0);

kompilator nie ma żadnych informacji o tym, jaki typ printf oczekuje tego drugiego argumentu. Ma tylko typ wyrażenia argumentu, którym jest int. Dlatego, w przeciwieństwie do większości funkcji bibliotecznych, to ty, programista, musisz upewnić się, że lista argumentów jest zgodna z oczekiwaniami ciągu formatu.

(Nowoczesne kompilatory mogą zajrzeć do ciągu formatu i powiedzieć, że masz niezgodność typów, ale nie zaczną wstawiać konwersji, aby osiągnąć to, co miałeś na myśli, ponieważ lepszy kod powinien się teraz zepsuć, kiedy zauważysz , niż lata później, gdy został przebudowany za pomocą mniej pomocnego kompilatora).

Teraz druga połowa pytania brzmiała: biorąc pod uwagę, że (int) 0 i (float) 0.0 są, w większości nowoczesnych systemów, reprezentowane jako 32 bity, z których wszystkie są zerowe, dlaczego i tak nie działa to przypadkowo? Standard C mówi tylko, że „to nie jest wymagane do pracy, jesteś sam”, ale pozwól mi przeliterować dwa najczęstsze powody, dla których to nie zadziała; to prawdopodobnie pomoże ci zrozumieć, dlaczego nie jest to wymagane.

Po pierwsze, z powodów historycznych, kiedy przechodzisz floatprzez zmienną listę argumentów, jest ona promowana do double, która w większości nowoczesnych systemów ma 64 bity. Zatem printf("%f", 0)przekazuje tylko 32 bity zerowe do wywoływanego, oczekując 64 z nich.

Drugim, równie istotnym powodem jest to, że argumenty funkcji zmiennoprzecinkowych mogą być przekazywane w innym miejscu niż argumenty liczb całkowitych. Na przykład większość procesorów ma oddzielne pliki rejestrów dla liczb całkowitych i wartości zmiennoprzecinkowych, więc może być regułą, że argumenty od 0 do 4 trafiają do rejestrów od r0 do r4, jeśli są liczbami całkowitymi, ale od f0 do f4, jeśli są zmiennoprzecinkowe. Więc printf("%f", 0)szuka w rejestrze f1 tego zera, ale w ogóle go tam nie ma.

Zwykle, gdy wywołujesz funkcję, która oczekuje a double, ale podasz an int, kompilator automatycznie przekonwertuje się na a double. Tak się nie dzieje w przypadku printf, ponieważ typy argumentów nie są określone w prototypie funkcji - kompilator nie wie, że należy zastosować konwersję.

Dlaczego użycie literału liczby całkowitej zamiast literału zmiennoprzecinkowego powoduje takie zachowanie?

Ponieważ printf()nie ma wpisanych parametrów oprócz const char* formatstringpierwszego. Do ...reszty używa się elipsy w stylu c ( ).

Po prostu decyduje, jak interpretować wartości przekazywane tam zgodnie z typami formatowania podanymi w ciągu formatu.

Wystąpiłbyś tak samo niezdefiniowane zachowanie, jak podczas próby

 int i = 0;
 const double* pf = (const double*)(&i);
 printf("%f\n",*pf); // dereferencing the pointer is UB

Użycie źle dopasowanego printf()specyfikatora "%f"i typu (int) 0prowadzi do niezdefiniowanego zachowania.

Jeśli specyfikacja konwersji jest nieprawidłowa, zachowanie jest niezdefiniowane. C11dr §7.21.6.1 9

Kandydujące przyczyny UB.

1. Jest to UB według specyfikacji, a kompilacja jest skomplikowana - powiedział nuf.

2. doublei intmają różne rozmiary.

3. doublei intmogą przekazywać swoje wartości przy użyciu różnych stosów (stos ogólny kontra FPU ).

4. A double 0.0 może nie być zdefiniowane przez wzorzec wszystkich bitów zerowych. (rzadko spotykany)

To jedna z tych wspaniałych okazji, aby wyciągnąć wnioski z ostrzeżeń kompilatora.

$ gcc -Wall -Wextra -pedantic fnord.c 
fnord.c: In function ‘main’:
fnord.c:8:2: warning: format ‘%f’ expects argument of type ‘double’, but argument 2 has type ‘int’ [-Wformat=]
  printf("%f\n",0);
  ^

lub

$ clang -Weverything -pedantic fnord.c 
fnord.c:8:16: warning: format specifies type 'double' but the argument has type 'int' [-Wformat]
        printf("%f\n",0);
                ~~    ^
                %d
1 warning generated.

Tak więc printfgeneruje niezdefiniowane zachowanie, ponieważ przekazujesz mu niezgodny typ argumentu.

Nie wiem, co jest niejasne.

Twój ciąg formatu oczekuje double; zamiast tego podajesz plikint .

To, czy te dwa typy mają tę samą szerokość bitową, jest całkowicie nieistotne, z wyjątkiem tego, że może to pomóc w uniknięciu wyjątków twardych naruszeń pamięci z powodu takiego zepsutego kodu.

"%f\n"gwarantuje przewidywalny wynik tylko wtedy, gdy drugi printf()parametr ma typ double. Następnie dodatkowe argumenty funkcji wariadycznych są przedmiotem domyślnej promocji argumentów. Argumenty całkowite są objęte promocją liczb całkowitych, co nigdy nie skutkuje wartościami zmiennoprzecinkowymi. I floatparametry są promowane nadouble .

Na domiar złego : standard pozwala na to, aby drugi argument był lub floatlub doublei nic więcej.

Dlaczego formalnie jest to UB, zostało omówione w kilku odpowiedziach.

Powód, dla którego otrzymujesz takie zachowanie, jest zależny od platformy, ale prawdopodobnie jest następujący:

• printfoczekuje swoich argumentów zgodnie ze standardową propagacją vararg. Oznacza to, że floatbędzie to doublei wszystko mniejsze niż intbędzie int.
• Przechodzisz przez, intgdzie funkcja oczekuje pliku double. Twój intjest prawdopodobnie 32-bitowy, twój double64-bitowy. Oznacza to, że cztery bajty stosu rozpoczynające się w miejscu, w którym powinien znajdować się argument 0, znajdują się , ale kolejne cztery bajty mają dowolną zawartość. To jest używane do konstruowania wartości, która jest wyświetlana.

Główną przyczyną tego problemu z „nieokreśloną wartością” jest rzutowanie wskaźnika na intwartość przekazaną do printfsekcji parametrów zmiennych do wskaźnika o doubletypach, któreva_arg makro.

Powoduje to odwołanie do obszaru pamięci, który nie został całkowicie zainicjowany wartością przekazaną jako parametr do printf, ponieważ doublerozmiar obszaru buforu pamięci jest większy niż introzmiar.

Dlatego też, gdy ten wskaźnik jest wyłuskiwany, zwracana jest nieokreślona wartość lub lepiej „wartość”, która zawiera częściowo wartość przekazaną jako parametr do printf, a dla pozostałej części może pochodzić z innego obszaru bufora stosu lub nawet obszaru kodu ( podnoszenie wyjątku błędu pamięci), prawdziwy przepełnienie bufora .


Może uwzględniać te konkretne fragmenty półproduktów implementacji kodu „printf” i „va_arg” ...

printf

va_list arg;
....
case('%f')
      va_arg ( arg, double ); //va_arg is a macro, and so you can pass it the "type" that will be used for casting the int pointer argument of printf..
.... 

rzeczywista implementacja w vprintf (biorąc pod uwagę GNU impl.) zarządzania przypadkami kodu parametrów o podwójnej wartości to:

if (__ldbl_is_dbl)
{
   args_value[cnt].pa_double = va_arg (ap_save, double);
   ...
}

va_arg

char *p = (double *) &arg + sizeof arg;  //printf parameters area pointer

double i2 = *((double *)p); //casting to double because va_arg(arg, double)
   p += sizeof (double);

Bibliografia

1. implementacja "printf" (vprintf) w glibc projektu gnu)
2. przykład kodu semplifikacji printf
3. przykład kodu semplifikacji va_arg