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 Mime-Version: 1.0 To: djgpp-workers AT delorie DOT com Cc: DJ Delorie Subject: Re: char != unsigned char... sometimes, sigh References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk 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 / \ /-_-_-_-_-_-_/