Sender:	vheyndri AT rug DOT ac DOT be
Message-Id:	<34D6F0E6.5B3D@rug.ac.be>
Date:	Tue, 03 Feb 1998 11:26:46 +0100
From:	Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
Mime-Version:	1.0
To:	djgpp-workers AT delorie DOT com
Cc:	DJ Delorie <dj AT delorie DOT com>
Subject:	Re: char != unsigned char... sometimes, sigh
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 980203120818 DOT 21682a-100000 AT is>

Eli Zaretskii wrote:
> 
> On Tue, 3 Feb 1998, Vik Heyndrickx wrote:
> 
> > > No, because the problem is that EOF ((int)-1) and 0xff ((int)(signed
> > > char)-1) ARE THE SAME NUMBER.  No amount of logic can tell the
> > > difference.
> >
> > This sort of difficulties is triggered by "choices made in the past",
> > where it was more efficient to return an error code at the same place
> > where the normal return value would be returned.
> 
> Sorry, you lost me.  Where was a ``normal return value'' replaced by an
> error code, and how does this relate to EOF (which is -1 on every
> platform I saw).

Getc returns the next character in the file stream (I call that
'normal'), unless it is at EOF in which occasion it returns an, allow me
to say, error code EOF.
This error code falls out of the "normal return" range when 'unsigned
char' is the default, but not for 'signed char': EOF is part of [-128 ..
127]

To illustrate what I said:

  int getc (FILE *f);

could also have been defined, IMO a MUCH MUCH MUCH better programming
practice:

  int getc (FILE *f, char *ret_c); // returns 0 to indicate that the
call succeeded
                                   // returns non-zero for failure or
EOF
                                   // the return char in *ret_c
  
In which case we would not be discussing to change 'char' to 'unsigned
char'.

Unfortunately, the functions are part of the standard and we therefore I
cannot alter them. So the ONLY option out of this mess I see, is
changing the default to 'unsigned char'

-- 
 \ Vik /-_-_-_-_-_-_/   
  \___/ Heyndrickx /          
   \ /-_-_-_-_-_-_/

- Raw text -