search

RPi-Distro / repo

Issue tracking for the archive.raspberrypi.com repo
37 stars 1 forks source link

getchar does not work in non blocking mode under Raspbian GNU/Linux 10 (buster) #193

Closed alphatech56 closed 2 years ago

alphatech56 commented 4 years ago

I tried to use getchar in non blocking mode. Program was working "as expected" with Raspbian GNU/Linux 9 (stretch). When I recompiled and run the same program with Raspbian GNU/Linux 10 (buster)" getchar always timed out, even if I typed characters on keyboard. Attached is code.

Expected behavior: If input buffer has no characters, getchar will time out after 3 seconds and return -1. If input buffer has at least one characters, getchar will return the first character in the buffer. This is how Raspbian GNU/Linux 9 (stretch) behaved.

Actual behavior under Raspbian GNU/Linux 10 (buster): getchar timed out immediately even if input buffer has characters.

It was discussion in https://github.com/popcornmix/omxplayer/issues/649, Suggestion was to use blocking mode. This is totally different mode of operation. testGetcharTxt.txt

XECDesign commented 2 years ago

Is this still an issue in Bullseye?

alphatech56 commented 2 years ago

Yes. this is still an issue in Bullseye with a little bit different behavior. If buffer has at list one character in the buffer, before getchar timed out first time, getchar will return the first character. If getchar timed out at least once, all charters will remind in the buffer and will be send to the shell after process is terminated

popcornmix commented 2 years ago

Isn't this a deliberate change. It sounds related to:

  • All stdio functions now treat end-of-file as a sticky condition. If you read from a file until EOF, and then the file is enlarged by another process, you must call clearerr or another function with the same effect (e.g. fseek, rewind) before you can read the additional data. This corrects a longstanding C99 conformance bug. It is most likely to affect programs that use stdio to read interactive input from a terminal. (Bug #1190
alphatech56 commented 2 years ago

I do not think that this is a deliberate change. Bug 1190 is dealing with fread(), I am taking about getchar(). Those are totally different functions. My scenario : If I use getchar() in a blocking mode, getchar() will wait until next character will be available and will return this character.
If I use getchar() in a none blocking mode and input buffer has no characters, getchar() should time out after 3 seconds and return -1. After that I should be able use getchar() again.

getchar() in a raw mode has no notion about EOT and absence of new character in stdin is not a EOT condition.