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

Hi AndyD,


Thanks... you are being enormously helpful.

I have a lot of things to test and try: and, as I enter my 2nd week of writing C++, it all take a much longer than it should.

But first, appologies: it seems I failed to make myself clear. When I say "My reading of the documentation is" that is shorthand for "I have been reading all the documentstion I can find, and I find it somewhat sketchy - vague and incomplete - but what I think it is trying to say is". This particular choice of words is intended to convey a significant level of uncertainty.

But to try to answer your question:

In the specific case of C++ lots of sites describe five possible outcomes:
1. fgets terminates because it reads the max number of characters before encountering a \n or the end-of-file condition (EOF)
2. fgets terminates on encountering a \n
3. fgets terminates on encountering EOF after reading some (at least one) Characters
In all these three cases the the buffer will contain all the characters read (including the \n if encountered) followed by \0; and the resut will be the same as the buffer
4. fgets terminates on encountering EOF before reading any Characters
5. fgets terminates on some genuine error condition
In both cases 4 and 5 the result will be NULL, and the buffer will be unaltered. In case 4 ferror, called after fgets, will return 0, but in case 5 ferror will return a non zero error code

Have I got this right?

I can find no documentation at all which describes the specific behaviour of fgets when the file is a FIFO. I'm pretty sure it removes the characters read from the FIFO - because that's the whole point of a FIFO; but I have so far failed to find any documentation that says this.

I can find no documetation about fopen blocking on a FIFO until a writer opens the FIFO or fgets on a FIFO blocking until a writer actually puts some data into the FIFO; but that does sound right. I will run the tests you suggest to investigate this.

I can find no documentation that suggests that fgets cares a hoot about whether some writer has the file open. Indeed, I have communication between C++ (the writer, written by one of my crew) and APL (the reader) that has been working fault free for several years where both programs keep the FIFO open all the time the system is running. fgets always blocks, and that seems to be sufficient.

Your say:

The "reader" code above will block in fopen until there is a "writer" on the FIFO, and fgets will block waiting for input from the FIFO, and will return NULL once the "writer" has exited. That is why there is a need for a loop and the fclose and then fopen. You want to block in fopen until there is a "writer" for the FIFO.

This is extarordinarily helpful... thanks. It answers the the final two points above, and shows how they are interconnected.

However, the evidence I have so far suggests that:
1. fgets in an APL frogram under Buster always blocks waiting for input and never return NULL, with no need for the writer to exit
2. fgets in a C++ program under Bookworm blocks initially blocks waiting for input, but after encountering some condition stops blocking.
Originally I thought this condition was "the first successful read using fgets", but I now realize that the condition could equally well be "on encountering EOF": my early tests would did not discriminate between these to cases.



Lots of things to try.... I'll be back. But all thoughts welcome.

And I do have one question, please.

In your code you have rather thanI understand how any non-zero value can be treated as TRUE; but is the comparison made with the pointer to the result (I'm guessing the null ponter is actually int 0) or to the value the pointer addresses. If it's the latter case. what happens if the value is the character string "\0"?

Now to work...


Cheers

Peter

Statistics: Posted by Peter Cyriax — Mon Feb 12, 2024 12:57 pm

---