X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-2.3 required=5.0 tests=AWL,BAYES_00
X-Spam-Check-By:	sourceware.org
Date:	Tue, 21 Apr 2009 18:13:37 +0200
From:	Spiro Trikaliotis <an-cygwin AT spiro DOT trikaliotis DOT net>
To:	cygwin AT cygwin DOT com
Message-ID:	<20090421161337.GG18867@trikaliotis.net>
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>
MIME-Version:	1.0
In-Reply-To:	<20090421152334.GH8722@calimero.vinschen.de>
User-Agent:	Mutt/1.5.17+20080114 (2008-01-14)
X-SA-Exim-Connect-IP:	87.163.239.24
X-SA-Exim-Mail-From:	an-cygwin AT spiro DOT trikaliotis DOT net
Subject:	Re: [1.7] Updated: cygwin-1.7.0-45
X-SA-Exim-Version:	4.2.1 (built Tue, 09 Jan 2007 17:23:22 +0000)
X-SA-Exim-Scanned:	Yes (on mail.trikaliotis.net)
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
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

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/

- Raw text -