I'm reading in a file with fgets(). It's a pretty big program with a lot
of memory allocated to data structures and such. But the file's not that
big, only about 70K.

About halfway through the file, fgets() returns a NULL. Right in the
middle of a line! I looked at the file, and there is definitely more
after the location where fgets is reporting an EOF. I checked feof and
ferror, and EOF was confirmed. The line it is reading in when it returns
a NULL is not longer than the size specified to fgets(), nor is the
buffer fgets is reading into too small.

Does anyone know what else might be causing this? I'm totally stumped.

Thanks,
Jason
--

C IO is allowed to fail for any reason. fgets() might be running out of
memory internally, or there might be something wrong with the file.

Try writing a little stub program that only calls fgets() and puts() on that
file. If it fails in the same place there is something wrong with the file.

If the file is OK try allocating less memory in your main program and
reducing your use of stack space (if this is large). If this fixes the
problem fgets() is running out of memory.

Then try writing your own fgets() with fgetc(). If this fixes the problem
then your fgets() is broken - unlikely but not impossible.

Also check for memory corruption - an illegal write could cause fgets() to
fail.
--

it *could* be an EOF in the file, and you're reading it in text mode instead
of binary mode.  but it's hard to say without seeing the code.  i realise
that it's a big program, but see if you can't trim it down to a few dozen
relevant lines of code and post it here; it'd be better than nothing to work
with :)

--
              /"\                              m i k e    b u r r e l l

               X        AGAINST HTML MAIL      http://mikpos.dyndns.org
              / \
--

What sort of data does the file contain?

Using what?

In which case the I/O library seems to be encountering some sort of
end of file marker. On some systems (including DOS and Windows)
when reading text streams some characters may be interpreted as indicating
the end of the file. In DOS and Windows the character with this honour is
concevtionally character 26 (CTRL-Z). You don't mention what OS you are
using but that is most likely your problem.

Even if it were this wouldn't cause fgets() to return a null pointer.

If the file is a genuine text file then somehow an end of file marker
seems to have become embedded in it. If it is a binary file then
you'll probably have to open it in binary mode (e.g. using "rb"
instead of "r" in the fopen() call) and should probably not be using
fgets() to read the data.

--
-----------------------------------------


-----------------------------------------
--

Sorry, I should've posted some of the code. Also, I forgot to mention that I'm
working on HP-UX 10.20, and that the file is a text file. Here's what I have
(basically).

    char line[2000];

      fp = fopen(inputFile, "r");

      if (fp == NULL)
      {
        printf("main(): File %s not found.\n", inputFile);
        exit(FAILURE);
      }

  while(fgets(line, sizeof(line), fp) != NULL)
  {
    /* Do some stuff with the line, including splitting it up into tokens
w/strtok() (I first copy the variable line into a temporary var to be split up)
and storing these tokens in a list structure, which is dynamically allocated */
  }
  if (feof(fp))
    printf("This is supposed to be GOOD\n");

--

More info. The file that I was reading below (inputFile), is a file that is
created by the program itself using fprintf(). The problem only happens when
I read this same file in later during the same run, and only after I append
the file's contents onto the end of another, empty file. It doesn't matter
how I do this append, such as with fgetc()->fputc, like so:

void filecat(char * inFile, char * outFile)
{
  FILE *in = fopen(inFile, "rt");
  FILE *out = fopen(outFile, "at");
   int c;

  if (in == NULL)
  {
    printf("filecat(): Error opening input file %s\n", inFile);
    exit(FAILURE);
  }

  if (out == NULL)
  {
    printf("filecat(): Error opening output file %s\n", outFile);
    exit(FAILURE);
  }

  while ((c = getc(in)) != EOF)
    putc(c, out);

  fclose(in);
  fclose(out);

or with fread()->fwrite(), or fgets()->fputs(). It doesn't matter whether I
read/write in binary or text mode. The same error occurs in the same place
every time; somehow, an EOF is read around 3/4 of the way through the file,
right in the middle of a line. However, if I interrupt this program PRIOR to
the append operation, and then use it as the input file on a separate run of
the program, no error obtains!!

Weirder still, if I write the file out normally, but use rename() on that
file instead of attempting to append the file to the end of an
empty/non-existent file, it works perfectly!!!

Finally, if I take any version of this file that the program creates (the
original, the rename()-d or the appended versions, and run diffs on them,
they all come out exactly the same!! So the exact same file causes an error
depending on how it is created?

I'm totally lost, please help!!!

J

--

Try doing fflush(out) in the while loop after each putc(out).
--

There is no "rt" file mode in C. The correct mode for opening a text file
for reading is "r".

Similarly use "a" here.

Consider the portable alternative

     exit(EXIT_FAILURE);

EXIT_FAILURE is defined in <stdlib.h> (along with EXIT_SUCCESS and exit()
itself).

Messy. You open the output file before you test whether the input file
failed. This could create an empty file when there was none and doesn't
close the output file (it is was opened successfully) before you exit.

OK, the particular copying mechanism is not significant.

It sounds like there is still something active on the file writer side.
However I don't think we're going to get very far with this unless you
post a minimal but complete program that demonstrates the problem.
That will include the code that writes to the file as well as the
code that reads from it. How big is the file itself?

--
-----------------------------------------


-----------------------------------------
--

Just a side note:  the 't' is a vendor-dependent extension.  HP-UX C compiler is
not the only offender; Watcom also has this extension.  HP-UX probably has it
for the same reason Watcom does.  Watcom allows you to modify the default read
mode from text to binary.
--

HP-UX is a Unix system. Unix systems don't make any distinction between
text and binary streams. They don't have to because the external
representation of a text file matches C's internal representation (i.e.
new-line terminated lines) so no translation is required. C89 defines
file modes in terms of prefixes. "at" is the same as "a" because it has
"a" as its prefix. C99 makes "at" undefined so the implementation
can do what it likes with it. The inportant thing is that if you want
to write correct C you use "a" not "at". As long as Watcom defaults
to text files it is conforming in this respect.

--
-----------------------------------------


-----------------------------------------
--

[snip]

I don't like the idea of doing an fflush() in a loop, it wastes CPU.
Plus the problem is apparently in the input file.  
I'd suggest doing an   fflush(in)  before the while-loop.  So as to
make sure the input file has been written, buffers flushed etc...

Other suggestion, EOF is used by getc() when encountering an error as
well as an EOF...  try using error() and ferror() to pinpoint if there
is an error on reading and/or writing.
e.g.

while ((c = getc(in)) != EOF)
   putc(c, out);

if (c== EOF)  /* it pretty much _has_ to be if we exit the loop */
    perror("Error on input file");

or
if  (err=ferror(in) )
{
    printf ("\nError %d on input file", err);
    printf ("\nSystem message is: %s", strerror(err));

Just suggestions tho.

Serge

------------------------------------------------------------------------------
  The opinions expressed are mine and none other's
------------------------------------------------------------------------------
Serge Marelli

(if replying by mail, remove the 'somewhere.not-' from my email adress)
--

If this is the "Why is EOF returned prematurely?" issue,
the answer was that the input file had been opened as a
text stream, on a system that interpreted an embedded ^Z
byte as EOF.  Another common error is the use of char c
instead of int c.
--

I suggest not - fflush() is only defined for output streams. fflush()ing
out after all output has been done, or at set intervals (keep a counter,
when counter hits 100 or 1000 or so, fflush(out) and reset counter), may
be an acceptable solution.

Richard
--

please don't do this. It results in Undefined Behaviour.

I'm afraid it doesn't do this.

--
"Perilous to us all are the devices of an art deeper than we possess
ourselves."
                Gandalf The Grey (discussing Windows NT)
--