Troubleshooting • Re: C++ fgets behaving very oddly on Bookworm (no other environment tested yet)

Hi AndyD,

Thank you.

You have explained the reason why the whole fifo is getting flushed. I will revert the program to its original design, so that it keeps the fifo open all the time, and see if this behaviour vanishes.

However I opened the and closed the fifo on each read to sove the first problem, which was:

On the first call to fgets it apparently works correctly, waiting untill there is data in the pipe, reading it upto and including the first \n character,, and flushing what it has read from the fifo. But thereafter it no longer waits for data to be present, but returns immediately from each call with rubbish in the input buffer (always 6 characters long) but no error on the read, maxing out one CPU core in a tight loop.

I think the correct behaviour is called "blocking mode). If so, the issue is that a sucessful call to fgets sets the mode to not_blocking

I have managed to fix this by opening the fifo (fopen) immediately before the call to fgets, and closing it (fclose) immediately after the fgets call returns. So it's only ever on the "first call" to fgets, which works. But this is clearly a bodge.

I will try using std::getline. I had not appreciated that std::getline ONLY terminates when it encounters a \n.


Actually... I agree that a bug in fgets does seem unlikely. There will be all manner of issues. That is why I spent several days testing this and trying to figure it out before posting... and the subject:

fgets behaving very oddly

was intended to convey that the behaviour is odd (which it is) without laying blame.

Just to get the terminology right can anybody confirm or correct this, please:

I think the correct behaviour is called "blocking mode). If so, the issue is that a sucessful call to fgets sets the mode to not_blocking

Peter

Statistics: Posted by Peter Cyriax — Sun Feb 11, 2024 12:02 pm

---