Sender: vheyndri AT rug DOT ac DOT be
Message-Id: <34990BDD.885691C2@rug.ac.be>
Date: Thu, 18 Dec 1997 12:41:17 +0100
From: Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
Mime-Version: 1.0
To: djgpp-workers AT delorie DOT com
Subject: Re: char != unsigned char... sometimes, sigh
References: <Pine DOT SOL DOT 3 DOT 95 DOT 971218114906 DOT 29011B-100000 AT dumballah DOT tvnet DOT hu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

molnarl AT cdata DOT tvnet DOT hu wrote:

> > I meant 'return ints in the range [-128..127] or -1'. Do I always have
> > to be *this* exact? I think it was obvious what I meant to say.
> 
> I understand what you said. Maybe my comment wasn't clear: I just don't
> understand how do you decide whether getc read an EOF(=-1) or an 0xff
> character (which is -1 too if you convert it).

I must admit I never thought this would happen, but you are right of
course.
But, since getc is only supposed to be used for text files, which don't
usually contain '\xff' characters, I don't think this is really a
problem. 
I've never seen a 'real' character value assigned to this value.
I see no workaround, but think the problem I originally stated is
majorly dominant over this one.
IIRC the '\xff' character (et al.) has been used in the past on file
systems with no exact file length entry in the directory. At least one
advantage, DJGPP would be compatible with programs written for those
file systems.