X-Recipient: archive-cygwin@delorie.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@spiro.trikaliotis.net>
To: cygwin@cygwin.com
Message-ID: <20090421161337.GG18867@trikaliotis.net>
Mail-Followup-To: cygwin@cygwin.com
References: <20090402171059.GE12738@calimero.vinschen.de> <20090331111757.GA22043@calimero.vinschen.de> <200904031037.n33Ab4Ma001073@mail.bln1.bf.nsn-intra.net> <20090403145139.GJ12738@calimero.vinschen.de> <200904211025.n3LAPf7a022955@mail.bln1.bf.nsn-intra.net> <20090421152334.GH8722@calimero.vinschen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
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@spiro.trikaliotis.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@cygwin.com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie.com@cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe@cygwin.com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin@cygwin.com>
List-Help: <mailto:cygwin-help@cygwin.com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Delivered-To: mailing list cygwin@cygwin.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/

