X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Tue, 21 Apr 2009 19:35:47 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: [1.7] Updated: cygwin-1.7.0-45
Message-ID: <20090421173547.GM8722@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <20090402171059 DOT GE12738 AT calimero DOT vinschen DOT de> <20090331111757 DOT GA22043 AT calimero DOT vinschen DOT de> <200904031037 DOT n33Ab4Ma001073 AT mail DOT bln1 DOT bf DOT nsn-intra DOT net> <20090403145139 DOT GJ12738 AT calimero DOT vinschen DOT de> <200904211025 DOT n3LAPf7a022955 AT mail DOT bln1 DOT bf DOT nsn-intra DOT net> <20090421152334 DOT GH8722 AT calimero DOT vinschen DOT de> <20090421161337 DOT GG18867 AT trikaliotis DOT net> <20090421165642 DOT GK8722 AT calimero DOT vinschen DOT de> <49EE0130 DOT 3040403 AT gmail DOT com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <49EE0130.3040403@gmail.com>
User-Agent: Mutt/1.5.19 (2009-02-20)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On Apr 21 18:24, Dave Korn wrote:
> Corinna Vinschen wrote:
> 
> > 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.
> 
>   Are you not implying we should break correct applications for
> "backward-compatibility" with broken ones?  The values 0xff and -1 are
> entirely distinct inputs as far as isblank() is concerned.

I'm not implying that at all.  It's just as it works right now.
The character class tables return the same value for signed and
unsigned chars with the same logical character value:

  isFOO (128) == isFOO (-127)
  isFOO (255) == isFOO (-1)

> "The isblank() function shall test whether c is a character of class blank in
> the program's current locale"
> 
> "The c argument is a type int, the value of which the application shall ensure
> is a character representable as an unsigned char or equal to the value of the
                                     ^^^^^^^^
That's the magic biscuit.

Applications which put a signed char with a negative value into the
ctype functions are by definition broken.  Unfortunately there are a lot
of that out there, especially written by people who only care for ASCII
anyway.

> macro EOF. If the argument has any other value, the behavior is undefined."
> 
>   How does SED cope with this on glibc systems, which also use signed chars
> and have had locale fully-supported for some time?

Look into their ctype header.  Quote from a comment in glibc's ctype.h:

   These point into arrays of 384, so they can be indexed by any `unsigned
   char' value [0,255]; by EOF (-1); or by any `signed char' value
   [-128,-1).  ISO C requires that the ctype functions work for `unsigned
   char' values and for EOF; we also support negative `signed char' values
   for broken old programs.


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/