X-Authentication-Warning: acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs Date: Mon, 14 Jun 1999 17:34:38 +0200 (MET DST) From: Hans-Bernhard Broeker X-Sender: broeker AT acp3bf To: Eli Zaretskii cc: djgpp-workers AT delorie DOT com Subject: Re: strtol In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Mon, 14 Jun 1999, Eli Zaretskii wrote: > > The rule is simple: a char that is to be passed to a functions > > must either already *be* a unsigned char, or be casted into one. > > Where is this rule spelled out? Nowhere, at least not in such strong terms. But the matter still holds: A variable of type 'signed char' (or 'char', if it's signed) cannot be passed into a function unchanged, because it may have a value that is neither inside the range of unsigned char, nor is it EOF, as the standard dictates for the arguments of the functions. The '& 0xff' trick only works because our machines use twos-complement for negative integers. So my vote would be to replace that c &= 0xff with c = (unsigned char) c; (and a comment, maybe). gcc -O0 seems to translate that into a 'movzbl' instruction, i.e. it zeros the other three bytes of 'c', which is 100% equivalent to a &0xff operation. > ANSI says that ctype functions accept an > int, including EOF (which cannot be casted to unsigned char; fixing that > in v2.02 was the reason these bugs came into existence in the first > place). But the int may not have any negative value other than EOF. The fact that you can get this result from the '&0xff' operation is all but obvious, which my primary concern with that method. Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Even if all the snow were burnt, ashes would remain.