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 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 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 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 Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , 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/