openssh unix dev - Feb 2023 - fseek/fgetc puzzle

Darren Tucker wrote this message on Fri, Feb 17, 2023 at 19:07
+1100:
> I've got a bit of a puzzle and I was wondering if anyone has any
insight
> as to what's going on.
> 
> I added some code to ssh's known_hosts handling that checks if the last
> byte in the file is a newline, and if not, it adds one before writing
> the new record.  I also wrote a regression test for this and in most
> cases this works fine.
> 
> On some platforms (Solaris, OpenIndiana and AIX) however, the test fails
> because it adds two newlines instead of the expected one.  Basically if
> I fseek to the end, read a byte and write a byte the first byte will
> be duplicated.  I reduced it to this test case:
> 
> #include <stdio.h>
> int main(void)
> {
>         FILE *f = fopen("testfile", "w");
>         putc('A', f);
>         fclose(f);
> 
>         f = fopen("testfile", "a+");  /* same behaviour
for r+ */
>         fseek(f, -1L, SEEK_END);
>         printf("c=%d\n", fgetc(f));
>         /* fseek(f, 0, SEEK_END);  -- with this it behaves as expected */
>         /* fflush(f);  -- this too */
>         fputc('B', f);
> }
> 
> $ gcc test.c && ./a.out; od -x -c testfile
> c=65
> 0000000    4141    0042
>            A   A   B
> 0000003
> 
> I wrote two bytes and read one but somehow ended up with three bytes in
> the file?  (This example is from Solaris 11 but AIX does the same thing).
> 
> On most platforms this behaves as expected:
> 
> $ cc test.c && ./a.out; od -x -c testfile
> c=65
> 0000000     4241
>            A   B
> 0000002
> 
> Now I could just add the fseek, but as far as I can tell I shouldn't
> have to, and I don't understand why.  I've read the specs and the
man
> pages and haven't found anything that would explain this behaviour.
> 
> I'm curious if anyone has a) any insight as to what's going on, or
b)
> any additional examples of where it fails?
Can you check the return value of fseek to see if it's non-zero?  It
should be zero if successful, but likely non-zero on the failing
systems.

I decided to check the C standard for fseek's behavior, and it looks
like SEEK_END is not specified on text streams, only binary streams
(at least in C99 and C2X).

For text streams, this is what it says is supported (C99 7.19.9.2):
For a text stream, either offset shall be zero, or offset shall be a
value returned by an earlier successful call to the ftell function on
a stream associated with the same file and whence shall be SEEK_SET.

Does it work if you open the file in binary mode?  a+b or r+b?

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."

On Mon, 20 Feb 2023 at 21:03, John-Mark Gurney <jmg at funkthat.com>
wrote:
[...]
> Can you check the return value of fseek to see if it's non-zero?  It
> should be zero if successful, but likely non-zero on the failing
> systems.
The fseek returns zero.  The real code[0] checks this and other return
values, but I omitted the check in the test case for brevity (and to
make it easier to truss/strace).
> I decided to check the C standard for fseek's behavior, and it looks
> like SEEK_END is not specified on text streams, only binary streams
> (at least in C99 and C2X).
>
> For text streams, this is what it says is supported (C99 7.19.9.2):
> For a text stream, either offset shall be zero, or offset shall be a
> value returned by an earlier successful call to the ftell function on
> a stream associated with the same file and whence shall be SEEK_SET.
In at least the Solaris man page that language seems to only refer to
use with wide characters:

"""
       If the stream is to be used with wide character input/output functions,
       offset must either be 0 or a value  returned  by  an  earlier  call  to
       ftell(3C) on the same stream and whence must be SEEK_SET.
"""
> Does it work if you open the file in binary mode?  a+b or r+b?
Same behaviour as before with both.

$ cat test.c
#include <stdlib.h>
#include <stdio.h>
int main(void)
{
        FILE *f = fopen("testfile", "w");
        printf("fputc A=%d\n", fputc('A', f));
        fclose(f);

        f = fopen("testfile", "a+b");
        printf("fseek=%d\n", fseek(f, -1L, SEEK_END));
        printf("c=%d\n", fgetc(f));
        printf("fputc B = %d\n", fputc('B', f));
}
$ gcc test.c && ./a.out && od -x -c testfile
fputc A=65
fseek=0
c=65
fputc B = 66
0000000    4141    0042
           A   A   B
0000003

[0]
https://github.com/openssh/openssh-portable/commit/3c379c9a849a635cc7f05cbe49fe473ccf469ef9

-- 
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.