Troubleshooting • Re: C++ fgets behaving very oddly on Bookworm

Hi Peter,

I really do think that the problem is not in the implementation of fgets, but your expectation of the behaviour of your program.

The fgets function is provided by the glibc library and is the same function independent of you using C or C++. It is a very commonly used function and any regression would be found quickly in Linux.

1. The behaviour occurrs under Bookworm, and I do say that I will test other environments: I will replace the Pi5 with a Pi 4 in order to do that. The subject was intended to convey information, not criticism: I have edited the subject to emphasize this.

Understood, but without a fully working example of the issue, it is very difficult to work out if this is an actual problem in fgets or a misunderstanding of the expected behaviour. If you could provide a minimal working example that would be a good start.

2. I have used fgets on a pi before, but embedd in an APL program, not C++, under Buster, and did not see this behaviour. I will, as I said run the C++ on older systems to establish the scope of this behaviour

That is a good idea.

3. I am testing this by sending input jessages from a terminal using fprintf. So yes... that almost certainly does open and close the fifo each time it is used, which would not be the case in the production system. However I I have tried putting multiple messages (each terminated by \n) in a single call from printf, and fgets reads (and correctly actions) only the first message. If I then try to cat or tail the fifo from another terminal (before or after terminating the C++ program) the messages that fgets has not read are not there, so it does look as if fgets flushes the whole fifo, not just the bit it has read, but I'll re-run these tests to check and re-post.

So the lines are consumed by your program, but don't appear in your output. That is a possible clue.

4. I am using fgets rather than getline because getline discards the terminating \n which means the C++ program has no way to tell if it has in fact received a complete message.

I disagree, but that is OK. The std::getline function will only read complete lines terminated by a newline, unless you have a line that is larger than the maxim string size, which is a little less than 5 GB (4,294,967,295 bytes) on my Raspberry Pi 5 8GB.

5. I have tried checking for errors on the fgets call:

Code:

     if (fgets(msgbuf, msglen, fd) == NULL){          printf("read error : %d\n", ferror(fd));      }

and no errors are reported

That is good, what about fopen?

6. Just to be clear, yes... I am trying to write a C++ program that, in effect, tails the fifo, receiving \n terminated messages one at a time, which it then actions. The program works absolutely fine provided that mesaages are written to the fifo one at a time, even in bits using multiple writes, and are less than 80 characters long. These assumptions are reasonable, but I don't want to leave them embedded in a production system that should run, unsupported, in multiple environments, for many years.

There are excellent aims. As I say above, it is highly unlikely that there is a bug in fgets, and more likely that your expectations of the programs behaviour are not complete.

7. I have taught myself what little I know about C++ starting a week ago by googling and reading helpful forums like this one. I am putting the message into a stringstream because they are defined as space delimited \n terminated strings, and I found I could then easily parse the message using getline with ' ' as the delimiter to convert the message into a vector of words. I'll read up about sockets and these other containers, but it's actually reading the fifo that is the only issue I currently have.

You already have each command in a buffer. It would be better to assign the buffer to a std::string and use C++ functions to remove the newline.

8. If I could find the source code of tail ...

I provided a link above to the source for the coreutils implementation of tail.

Statistics: Posted by AndyD — Sun Feb 11, 2024 10:36 am

---