GCC, newlib/libgloss: Frage zur Anpassung der _read() Funktion

Niklas G. schrieb:
> Ralf schrieb:
>> dann können die auch EOF (= kein Zeichen empfangen = Rückgabewert 0)
>> zurückliefern.
Korrektur: Ich hab hier einen Fehler, EOF ist nicht 0, sondern -1.

> Aber nur im Fehlerfall oder eben bei End Of File. Wenn einfach nur keine
> Zeichen da sind, soll _read() blockieren. Wie sonst soll scanf() darauf
> warten, dass alles angekommen ist?
Meine Vermutung(!) wäre, dass scanf() _read() solange aufruft bis != EOF 
zurückgegeben wird.

Ralf

Niklas G. schrieb:
> Ralf schrieb:
>> Meine Vermutung(!) wäre, dass scanf() _read() solange aufruft bis != EOF
>> zurückgegeben wird.
> Nene, das wäre ja super ineffizient. Bei EOF kehrt scanf() sofort
> zurück. Schau doch in den Sourcecode von scanf()...
Dann versteh ich nicht, unter welchen Umständen getchar() überhaupt EOF 
zurückgibt, wenn STDIN als Eingabe verwendet wird? Bei getc() ist es 
klar, das bekommt einen FileDescriptor mitgeteilt, da kann (wird) EOF 
dann vorkommen.

Für den Sourcecode meinst du sourceware.org? Ich schau mal ob ich mich 
da zurechtfinde :)

Vielleicht sollte ich besser schildern, was ich vorhabe: ich möchte 
einzelne Zeichen vom UART lesen - alle Zeichen bis auf ein spezielles 
sollen ganz normal weiter an eine andere Funktion durchgereicht werden.
Wenn das spezielle Zeichen empfangen wird, dann soll über eine bestimmte 
Zeit geprüft werden, ob weitere Zeichen empfangen wurden oder nicht. 
Wenn ja, alles inklusive des speziellen Zeichens weiter durchreichen, 
ansonsten eben was spezielles machen.
Also im Prinzip beim Empfang des speziellen Zeichens einen Timeout auf 
den Empfang weiterer Zeichen einrichten.

Mit einem nicht blockierenden _read() unter der Haube, welches EOF für 
"keine Daten vorhanden" ausspuckt hätte ich nun gedacht, dass das gehen 
könnte, bspw. mit getchar().

Also mal der aktuelle Fragenkatalog:
1) _read() muss blockierend sein und kann kein EOF liefern?
2) Unter welchen Umständen spuckt getchar() dann ein EOF aus, wenn 
dieses nicht von _write() kommen kann?
3) Wie richtet man eine nicht blockierende Abfrage von STDIN ein? 
getc()/getchar() in Kombination mit ungetc() auf STDIN?

Ralf

Hab da grad nochmal genauer drüber nachgedacht:

> 1) _read() muss blockierend sein und kann kein EOF liefern?
Anstatt EOF für keine Daten würde ja 0 auch gehen, wenn nichts im Buffer 
ist - read() gibt ja die Menge der gelesenen Daten zurück. Kommt scanf() 
dann eher damit klar? Das würde es scanf() auch ermöglichen zu prüfen ob 
was angekommen ist. Damit wäre es aber trotzdem nicht blockierend.

Ralf

Rolf M. schrieb:
>> 3) Wie richtet man eine nicht blockierende Abfrage von STDIN ein?
>> getc()/getchar() in Kombination mit ungetc() auf STDIN?
> Nein. In Standard-C gibt's keinen Weg dafür.
Das ist wohl korrekt, wie ich mittlerweile feststellen musste.

> Ralf schrieb:
>>> 1) _read() muss blockierend sein und kann kein EOF liefern?
>> Anstatt EOF für keine Daten würde ja 0 auch gehen, wenn nichts im Buffer
>> ist - read() gibt ja die Menge der gelesenen Daten zurück.
> Ja, und wenn es keine Daten mehr lesen kann, liefert es das zurück, was
> dann bedeutet, dass das EOF erreicht ist. Wenn gerade keine Daten
> verfügbar sind, liefert es nichts zurück, weil es blockiert.
Habe den von Niklas implizierten Versuch durchgeführt, also scanf() mit 
einem nicht blockierenden _read() - scanf() ist wie von Niklas erwartet 
sang- und klanglos durchgerauscht :)

Ich muss mir mal überlegen wie ich das lösen kann. Notfalls muss ich 
eben doch den UART-Puffer vorher prüfen ob was drin ist, das wollte ich 
eigentlich vermeiden.

Danke euch beiden.

Ralf