🚀 go-pugleaf

Also sent to INFO-C
   Bug in fopen/getc
System ATARI 1040 ST
Compiler Megamax v1.1
    Since this is a problem with a specific compiler/system
I don't know if this is the right place for this question but maybe it 
happens on other systems. 

     I open a file with fopen and read it with getc until it returns
EOF . Then I try to read another byte. After I close the file the size 
has increased by one byte even though it was opened for read-only !

 A real case happens in ST GEM KERMIT in function bufill() which is
based on an old C-KERMIT.  After sending a source file a garbage byte 
appeared at the end and caused an error the next time I compiled it.
I moved a feof() to before the getc() to fix it.
example:
----------------------------------
#include <stdio.h>
char *filnam;
FILE *fd;
int ic;
main(argc,argv)
int argc;
char *argv[];
{
if(argc < 2){
            puts("no filename");
            exit(1);}
filnam=argv[1];
puts(filnam);
fd=fopen(filnam,"r");  /*  strips \r */
/* fd=fopen(filnam,"br"); */      /*  binary read */
while(getc(fd) != EOF);     /* read to EOF */
ic=getc(fd);                /* get next byte */
printf("ic= %d\n",ic);  /* ic should be -1 */
fclose(fd);
}
-----------------------------------
     Create a small file and find its length. Run this program to
read the file then check the length again. It is one byte more.
    Note: On the Megamax fopen() the "br" option is a 'binary' read
which reads everything from the file . The 'normal' read "r" causes
Carriage-returns (\r) to be ignored when reading. Either way it still
increases the length.

    When I tried reading beyond the end-of-file with low level IO
( open() and read() ) the file length is not increased so it appears
the error is in fopen/getc/fclose.

    I don't have the sources of the IO library but they are written
in C and appear to be based on standard UNIX functions - getc() is
a macro :
#define getc(p) (--(p)->_cnt >= 0 ? *(p)->_ptr++ & 0377 : _fillbuf(p))
    Does this happen on any other system ? I only have access to
VAX-VMS C which has a quite different IO system .

David Dermott (DERMOTT@DREA-XX.ARPA)
DREA
Dartmouth Nova Scotia
-------