My data file contains bytes such as 0x1A which causes my loop to stop when
checking for EOF.
e.g.
while((cTempChar =  fgetc(pFile)) != EOF)

Is there another way to know when the end of a file is reached?

It seems that you're talking about some OS-specific way of
specifying the end of file.  You should probably ask in a forum
dedicated to your OS.

Josh> My data file contains bytes such as 0x1A which causes my loop
Josh> to stop when checking for EOF.
Josh> e.g.
Josh> while((cTempChar =  fgetc(pFile)) != EOF)

Josh> Is there another way to know when the end of a file is reached?

Yeah -- don't use a char to hold the result of fgetc.

        int cTempChar;

Did you open the file in binary ???

{
  int tmp;

  while((tmp = fgetc(pFile)) != EOF)
  {
    unsigned char uc = (unsigned char) tmp ;
    /* The cast is superfluous, but (IMHO) useful for explanatory
     * purposes */

    /* Do stuff to your character here */
  }

ifstream pFile ("myfile.dat");

char cTempChar;
while (pFile.get(cTempChar))
{
   // do something with cTempChar

        http://www.eskimo.com/~scs/C-faq/top.html

The C language streams provide a platform-independent abstraction of
text file in the form of streams that can be open in a text mode. In
text mode, ANSI C streams perform whatever translation is necessary on
input and output to make the stream look sane to the programmer. Lines
appear to be terminated with single newline characters ('\n'), and
there doesn't appear to be any special character marking the end of
the file.

You have two problems here. Firstly, the result of fgets() is type
int, not type char. The reason it is of type int is to that it can
return a character value, or the special value EOF which *is not a
character*, but an abstract indication which says that no more
characters are available, or an I/O error occured! If you try to
capture this value using a char type, can run into problems due to the
narrowing conversion yielding false indicators---legitimate character
values that turn into EOF, or the opposite problem: the EOF value
turning into something that is not equal to EOF.

Secondly, you are probably trying to read a binary file, but opened
the stream in text mode! So the library is interpreting the first
random occurence of the byte 0x1b as the end of what it thinks is a
text file; and what's worse, you are getting line ending conversion.

Last draft C89:
The fgetc function returns the next character from the input stream
pointed to by stream .  If the stream is at end-of-file, the
end-of-file indicator for the stream is set and fgetc returns EOF .
If a read error occurs, the error indicator for the stream is set and
fgetc returns EOF .
   The feof function returns nonzero if and only if the end-of-file
indicator is set for stream .

feof() will allow you to distinguish between an end-of-file condition
and another condition that would make fgetc() return EOF, like an input
error, for example (see also ferror()). Most likely on the OP's OS the
presence of 0x1A in the file is a valid end-of-file condition.

If you open the file in binary mode, characters like 0x1A lose their
special meaning and fgetc() will keep reading until the physical end
of file is reached.

BTW, EOF is a negative value, so be sure to declare cTempChar as
int, otherwise you may be unable to discern between EOF and a legit
character value (short of using the feof() function).

Consider a typical example: char is a signed type and the file only
contains ASCII characters.  Using char instead of int will not affect
the expected behaviour of the code.

Later, the convention was adopted by other operating systems, for
compatibility purposes: it allowed the more sophisticated OS (which
didn't need the convention at all for its native text files) to import
text files from the older OSs and still be able to properly detect the
logical end of the file.

There is no idiocy involved here (except that of the programmer who
opens a binary file in text mode).