Przechowywanie znaku EOF (End of File) w typie char

Przeczytałem książkę Dennisa Ritchiego The C Programming Language, której intnależy użyć, aby zmienna mogła przechowywać EOF - aby była wystarczająco duża, aby mogła przechowywać wartość EOF - nie char. Ale następujący kod działa dobrze:

#include<stdio.h> 

main()  { 
  char c; 
  c=getchar(); 
  while(c!=EOF)  { 
    putchar(c); 
    c=getchar(); 
  } 
} 

Gdy nie ma już danych wejściowych, getcharzwraca EOF. W powyższym programie zmienna ctypu char jest w stanie ją z powodzeniem zatrzymać.

Dlaczego to działa? Zgodnie z wyjaśnieniem w powyższej książce kod nie powinien działać.

Twój kod wydaje się działać, ponieważ przypadkowe konwersje typów przypadkowo robią to, co należy.

getchar()zwraca an intz wartością, która albo pasuje do zakresu, unsigned charalbo jest EOF(co musi być ujemne, zwykle wynosi -1). Zauważ, że EOFsam nie jest postacią, ale sygnałem, że nie ma już dostępnych znaków.

Podczas przechowywania wynik z getchar()IN c, istnieją dwie możliwości. Albo typ charmoże reprezentować wartość, w którym to przypadku jest to wartość c. Lub typ char nie może reprezentować wartości. W takim przypadku nie jest określone, co się stanie. Procesory Intela po prostu odcinają wysokie bity, które nie pasują do nowego typu (skutecznie zmniejszając wartość modulo 256 dla char), ale nie powinieneś na tym polegać.

Następnym krokiem jest porównanie cz EOF. Jak EOFjest int, czostanie przekonwertowany na intrównież, zachowując wartość przechowywaną w c. Jeśli cmożna zapisać wartość EOF, wówczas porównanie się powiedzie, ale jeśli niec można zapisać wartości, porównanie się nie powiedzie, ponieważ nastąpiła nieodwracalna utrata informacji podczas konwersji na typ .EOFchar

Wygląda na to, że Twój kompilator zdecydował się na charpodpisanie typu, a wartość na EOFtyle mała, aby zmieściła się char. Gdyby charbyły niepodpisane (lub gdybyś użył unsigned char), test nie powiódłby się, ponieważ unsigned charnie można utrzymać wartości EOF.

Pamiętaj również, że jest drugi problem z twoim kodem. Ponieważ EOFnie jest postacią samą w sobie, ale wymusza się na niej chartyp, istnieje bardzo prawdopodobieństwo, że zostanie źle zinterpretowana jako istota, EOFa dla połowy możliwych znaków nie jest zdefiniowane, czy zostaną poprawnie przetworzone.