X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 	tests=AWL,BAYES_00,SPF_PASS
X-Spam-Check-By: sourceware.org
Message-ID: <49EE0130.3040403@gmail.com>
Date: Tue, 21 Apr 2009 18:24:00 +0100
From: Dave Korn <dave DOT korn DOT cygwin AT googlemail DOT com>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: [1.7] Updated: cygwin-1.7.0-45
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>
In-Reply-To: <20090421165642.GK8722@calimero.vinschen.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.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

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.

"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
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?

    cheers,
      DaveK

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