This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [1.7] Updated: cygwin-1.7.0-45


On Apr 21 18:13, Spiro Trikaliotis wrote:
> 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.

I didn't explain that well enough.  The problem is not the char value
0xff if it's defined as unsigned char value as expected by the ctype
functions.  The problem is how to treat this value if it's given as
signed char value to the ctype functions by broken applications and for
backward compatibility.  In this special case it's -1 and so it has the
same value as EOF.  The change in the library should not result in
breaking an existing application.  So the value -1 when given to the
ctype functions should always return the equivalent value for EOF, not
the value for the character 0xff.  That's what must be fixed.  The fact
that sed would be better off with a fix as well was not part of the
discussion.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]