Re: Buffer contents well-defined after fgets() reaches EOF ?

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

On 2/11/25 16:59, Keith Thompson wrote:

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

...

I just tried it, using gcc and found that fgets() does set the first
byte of the buffer to a null character. Therefore, it doesn't conform to
the requirements of the standard. That's not particularly surprising -
calling fgets with useless arguments isn't something that I'd expect to
be a high priority on their pre-delivery tests.

>
As you know, gcc doesn't implement fgets(). Were you using GNU lib

.
Yes. To be specific, Ubuntu GLIBC 2.35-0ubuntu3.9.
>
Here's my test code:
>
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[])
{
char fill = 1;
char buffer = fill;
char *retval = NULL;
FILE *infile;
if(argc < 2)
infile = stdin;
else{
infile = fopen(argv[1], "r");
if(!infile)
{
perror(argv[1]);
return EXIT_FAILURE;
}
}
>
while((retval = fgets(&buffer, 1, infile)) == &buffer)
{
printf("%ld:'%u'\n", ftell(infile), (unsigned)buffer);
buffer = fill++;
}
if(ferror(infile))
perror("fgets");
>
printf("%p!=%p ferror:%d feof:%d '%c'\n",
(void*)&buffer, (void*)retval,
ferror(infile), feof(infile), buffer);
}
>
Note that if fgets() works as it should, that's an infinite loop, since
no data is read in, and therefore there's no movement through the input
file. I wrote code that executes after the infinite loop just to cover
the possibility that it doesn't work that way.

I get an infinite loop with both glibc and musl on Ubuntu, and under
Termux on Android (Bionic library implementation):

$ ./jk < /dev/null | head -n 3
0:'0'
0:'0'
0:'0'
$ echo hello | ./jk | head -n 3
-1:'0'
-1:'0'
-1:'0'
$

With newlib on Cygwin, there is no infinite loop:

$ ./jk.exe < /dev/null
0x7ffffcc17!=0x0 ferror:0 feof:0 ''
$ echo hello | ./jk.exe
0x7ffffcc17!=0x0 ferror:0 feof:0 ''
$

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */