Hi

I am trying to get some C that I wrote for an ACORN
to run on a PC.

The program reads a text file of data and does some
calculations. It works fine on the ACORN but does not
behave on the PC.

The problem is the the data text file has character
0x1a in it to seperate different chunks of data.
On the PC 0x1a indicates an EOF condition so that
even if the filepointer is not at the EOF getc()
seems to think that EOF has occurred.

int
count_the_chunks( FILE *fp , int * num_chunks)
{
/* this simply counts the number of 0x1a characters in the file
 * file has already been opened by fopen() as a text file for reading
 */
        int c, i;
        *numchunks = 0;

        while( c = getc( fp ) != EOF)
        {
                if ( c == 0x1a )
                        *numchunks ++;
        }

        if ( c == EOF )
                return( 1 );

        return( 0 );

Does anyone know of a simple way on the PC to differentiate between
the character 0x1a and the actual EOF?

If you open the file in binary mode ("rb"), this will
not happen.  A side effect is that you'll also be getting
\n as \r\n. (And doing a seek will be more straightforward).

Bye!
--
Miguel Carrasquer         ____________________  ~~~
Amsterdam                [                  ||]~  

Actually your problem is that you have just described a binary file, not
a data text file.  Open the file in binary mode.  Of course you have to
be prepared to deal with the fact the conversion from CR/LF pairs to C
newline ('\n') won't be performed.

How can this not be EOF given the loop test above?  Given that the return
conveys no information as you wrote it may I suggest:

int
count_the_chunks(FILE *fp)
{
    int c, numchunks = 0;

    while (c = getc(fp) != EOF)
        if (c == 0x1a)
            numchunks++;

        return (numchunks);

That way you can use the return directly in an expression.

--

PlanIX, Inc.                        |   Thank goodness we don't get
Toronto, Ontario, Canada            |   all the government we pay for.
+1 416 424 2871  (DoD#0082) (eNTP)  |

didnt see the original post but, quote from man pages... in case anyone cares

          DIAGNOSTICS
               These functions return the constant EOF at end-of-file or
               upon an error.  If an attempt is made to read from a stream
               that has not been opened in read mode, errno is set to
               EBADF.  Because EOF is a valid integer, ferror(3S) should be
               used to detect getw errors.             ^^^^^^

          WARNING <<<<<<<<<<<<<<<<<<<<<<
               If the integer value returned by getc, getchar, or fgetc is
               stored into a character variable, then compared against the
                             ^^^^^^^^^^^^^^^^^^
               integer constant EOF, the comparison may never succeed
               because sign-extension of a character on widening to integer
               is machine-dependent.

                      ^^^^

Since the quoted section talks about getw and getw only, it has no
relevance for getchar, getc, and fgetc.  For the these functions,
an EOF return value _always_ has one meaning and one meaning only:
that the read tried to go past the end of the file.

getw is a non-standard function that has very little use.

This section explains why one must not ever store the return value
of getchar, getc, or fgetc in a variable that has a smaller type than
int.  You can find the same information in this newsgroups FAQ.

--

My name is Ozymandias, king of kings/Look on my works, ye Mighty, and despair!

These should both be:
        while( (c = getc(fp)) != EOF)
I still have vivid memories of being bitten by this when I first
started writing in C.  Always put brackets around c=fgetc!!

--
Miguel Carrasquer         ____________________  ~~~
Amsterdam                [                  ||]~  

|> >      Because EOF is a        valid integer, ferror(3S) should be
|> >      used to detect getw errors.     ^^^^^^
|>                       ^^^^
|>
|> Since the quoted section talks about getw and getw only, it has no
|> relevance for getchar, getc, and fgetc.  For the these functions,
|> an EOF return value _always_ has one meaning and one meaning only:
|> that the read tried to go past the end of the file.
|>
|> getw is a non-standard function that has very little use.
|>
|> >        WARNING <<<<<<<<<<<<<<<<<<<<<<
|> >             If the integer value returned by getc, getchar, or fgetc is
|> >             stored into a character variable, then compared against the
|> >                           ^^^^^^^^^^^^^^^^^^
|> >             integer constant EOF, the comparison may never succeed
|> >             because sign-extension of a character on widening to integer
|> >             is machine-dependent.
|>
|> This section explains why one must not ever store the return value
|> of getchar, getc, or fgetc in a variable that has a smaller type than
|> int.  You can find the same information in this newsgroups FAQ.
|>
|> --

|> My name is Ozymandias, king of kings/Look on my works, ye Mighty, and despair!

This is probably the most cumbersome aspect of the C language.
Functions that return a value that is real data or a "fault"
condition, such as end-of-file. In the old'n days, it was a big
overhead to put a variable on the stack, with today's processors
it really ain't that big a deal.

It would make sense to redefine routines such as getc as:

boolean = getc(&input_char)

if boolean == FALSE, then no character was read, if TRUE
then a character was placed in input_char.

but, before I'm flamed, unmercifully, I love C and don't
advocate changing it(too much) :-)
--

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

The philosophy of the classroom will be the philosophy of the
government in the next generation.
                                     -- Abraham Lincoln

Public opinion is a weak tyrant compared with our own
private opinion.
                                     -- Thoreau
-----------------------------------------------------------------