This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: [1.7] Updated: cygwin-1.7.0-45
Hello,
* On Tue, Apr 21, 2009 at 05:23:34PM +0200 Corinna Vinschen wrote:
> On Apr 14 19:08, Thomas Wolff wrote:
> > On April 14, Corinna Vinschen wrote:
[...]
> This is a real problem. In the OEM codepages the 0xff character is a
> non-breaking space. Unfortunately there's no way to distinguish between
> the (signed) char value 0xff and EOF when it's put as argument into the
> ctype functions. sed has a loop which loops over all blank characters
> in the input, basically like this:
>
> do {
> ch = inchar ();
> } while (isblank (ch);
>
> As soon as inchar() is at the end of the input, it returns EOF == -1. And
> then the loop never stops, because the character value -1 is a blank
> character.
>
> However, this appears to be a generic problem with the character with
> value 0xff. If char is signed, its value is -1 and it can't be
> distinguished from EOF.
>
> The only solution for this problem is, AFAICS, to treat the character
> 0xff as a non-character, for which all ctype functions return 0.
No. The real solution is to define ch as int in the first place. This
way, ch = 0xff is the printable character, while ch = -1 is EOF. Look at
the prototypes of the functions in ctype.h, they all take int as an
argument. And getchar(), getc() and getch() all return an int, not a
char. There's a reason for this.
Regards,
Spiro.
--
Spiro R. Trikaliotis http://opencbm.sf.net/
http://www.trikaliotis.net/ http://www.viceteam.org/
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/