Post by t***@bsod.orgsetbuf(stdin,NULL)
o ile rozumiem, po tym stdin przejdzie w tryb unbuffered, a potem
przy pierwszym lepszym odczycie z stdin, system znowu zalozy mu bufor?
Nie, bo jest też bufor po stronie jądra. Jeśli proces zrobi
read(fd, buf, N), a z poprzedniej linii nic nie zostało do wczytania,
to jądro wczyta całą linię, a procesowi przekaże tylko pierwsze N
bajtów. Gdyby nawet pozbyć się tego, co zbuforował sobie proces,
to efekt będzie dość arbitralny, zależny od tego, ile biblioteka C
sobie wewnętrznie buforuje.
Jeszcze gorzej będzie, jeśli wejście jest przekierowane z pliku.
Wtedy read() może zwrócić więcej niż jedną linię, więc w prywatnym
buforze procesu są dane, których nie chcemy wyrzucać.
Tu nie chodzi o bufor. To jest źle postawiony problem. Traktujmy wejście
jako ciąg znaków, być może pochodzący z klawiatury. Użytkownik wpisał
jakieś znaki, potem wcisnął Enter. Musimy coś z tymi wszystkimi znakami
przed Enterem zrobić, a może być ich dowolnie dużo. Być może chcemy
je zignorować, może zinterpretować jako kolejne instrukcje mimo braku
Entera między nimi, a może powiedzieć użytkownikowi, że dziwne rzeczy
wpisał po tym pierwszym znaku i nie wiemy, co przez to rozumie. Ale
trzeba te dane przeczytać, a koniec tych danych nie jest na żadnym
końcu bufora, tylko tam, gdzie pojawił się Enter, który też oczywiście
wczytujemy, zanim przejdziemy do danych za nim.
Chyba że plik skończył się wcześniej. W każdej sytuacji musimy być
też gotowi na koniec pliku i jakoś na niego zareagować. stdio nie
będzie próbowało czytać za końcem pliku (jeśli nie użyjemy clearerr),
więc jeśli natrafimy na koniec pliku, to trzeba coś sensownego zrobić
- na pewno nie np. kręcić się w kółko czekając na Enter, którego
nigdy nie będzie.
Więcej autorowi pierwotnego pytania nie odpowiem, bo był nieuprzejmy.
--
__("< Marcin Kowalczyk
\__/ ***@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/