character/byte equality, again

[Christopher Benson-Manica]

Does the code below make any non-portable assumptions other than
CHAR_BIT==8?

char buf[100];

/* do things with buf */

if( !(buf[0]^0xFF) ) /* assume CHAR_BIT is 8 - test for equality */
/* whatever */

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[Arthur J. O'Dwyer]

On Tue, 2 Mar 2004, Christopher Benson-Manica wrote:

Does the code below make any non-portable assumptions other than
CHAR_BIT==8?

char buf[100];

/* do things with buf */

if( !(buf[0]^0xFF) ) /* assume CHAR_BIT is 8 - test for equality */

On a sane implementation, I think this line would always be
equivalent to either

if (buf[0] == (char)0xFF)

or

if ((unsigned char)buf[0] == 0xFFu)

But on an unreasonable yet conforming implementation the evaluation
of (buf[0]^0xFF) could trap, invoking undefined behavior. (On such
implementations, 'char' would necessarily be signed and have one trap
representation.)
In short: I can't think of any use for this construct, and it's
more dangerous than it is helpful, so I would avoid it like the
plague.

-Arthur

[Richard Bos]

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote:

But on an unreasonable yet conforming implementation the evaluation
of (buf[0]^0xFF) could trap, invoking undefined behavior. (On such
implementations, 'char' would necessarily be signed and have one trap
representation.)

I don't think char is allowed to have trap representations. Unsigned
char certainly isn't, but surely neither is signed char?

Richard

[Arthur J. O'Dwyer]

On Wed, 3 Mar 2004, Richard Bos wrote:

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote:

But on an unreasonable yet conforming implementation the evaluation
of (buf[0]^0xFF) could trap, invoking undefined behavior. (On such
implementations, 'char' would necessarily be signed and have one trap
representation.)

I don't think char is allowed to have trap representations. Unsigned
char certainly isn't, but surely neither is signed char?

I don't see why not. Consider the case of ones' complement signed
char, in which 11111111 ("negative zero") is a trap representation.
Now make plain char signed. :)

-Arthur

[Chris Torek]

>On Tue, 2 Mar 2004, Christopher Benson-Manica wrote:

Does the code below make any non-portable assumptions other than
CHAR_BIT==8?

char buf[100];

/* do things with buf */

if( !(buf[0]^0xFF) ) /* assume CHAR_BIT is 8 - test for equality */

In article <news:Pi**********************************@unix48. andrew.cmu.edu>
Arthur J. O'Dwyer <aj*@nospam.andrew.cmu.edu> wrote: On a sane implementation, I think this line would always be
equivalent to either

if (buf[0] == (char)0xFF)

or

if ((unsigned char)buf[0] == 0xFFu)
Why would you think that?

The operands of the "^" operator are subject to the usual arithmetic
promotions (and constrained to be integers, hence really just the
integer promotions). If plain char is signed, then, and if buf[0]
holds 0xff with CHAR_BIT being 8, buf[0] must be signed and represents
the value -1. Of course, int is at least 16 bits, and a typical
implementation would wind up with the bit pattern 0xffff or 0xffffffff
on the left. The right is just the integer constant 0xff or (int)255,
and the result of the xor is likely to be 0xff00 or 0xffffff00.
But on an unreasonable yet conforming implementation the evaluation
of (buf[0]^0xFF) could trap, invoking undefined behavior. (On such
implementations, 'char' would necessarily be signed and have one trap
representation.)
Yes, this is also possible. I think the fact that it does not
work on most real implementations is more important, though. :-)
In short: I can't think of any use for this construct, and it's
more dangerous than it is helpful, so I would avoid it like the
plague.

Indeed.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[pete]

Arthur J. O'Dwyer wrote:

On Wed, 3 Mar 2004, Richard Bos wrote:

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote:

But on an unreasonable yet conforming implementation the evaluation
of (buf[0]^0xFF) could trap, invoking undefined behavior. (On such
implementations, 'char' would necessarily be signed and have one trap
representation.)

I don't think char is allowed to have trap representations. Unsigned
char certainly isn't, but surely neither is signed char?

I don't see why not. Consider the case of ones' complement signed
char, in which 11111111 ("negative zero") is a trap representation.
Now make plain char signed. :)

I believe that it's also possible to have SCHAR_MAX equal 127
and SCHAR_MIN equal -127, when CHAR_BIT is greater than 8.

--
pete

[Dan Pop]

In <c2*********@enews4.newsguy.com> Chris Torek <no****@torek.net> writes:

The operands of the "^" operator are subject to the usual arithmetic
promotions (and constrained to be integers, hence really just the
integer promotions).

Chris, please use the C terminology correctly.

1. There is no such thing as "usual arithmetic promotions".

2. The integer promotions are limited to types shorter than int. Beyond
that, it is the "usual arithmetic conversions" that operate, even in a
purely integer expression.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Chris Torek]

>In <c2*********@enews4.newsguy.com> Chris Torek <no****@torek.net> writes:

The operands of the "^" operator are subject to the usual arithmetic
promotions (and constrained to be integers, hence really just the
integer promotions).

In article <news:c2**********@sunnews.cern.ch>
Dan Pop <Da*****@cern.ch> writes:Chris, please use the C terminology correctly.

1. There is no such thing as "usual arithmetic promotions".

2. The integer promotions are limited to types shorter than int. Beyond
that, it is the "usual arithmetic conversions" that operate, even in a
purely integer expression.

Sorry, have not been getting much sleep lately. I knew something was
off even as I wrote that -- but I figured it had been at least a day
and nobody had yet pointed out that the expression did not actually
*work*. :-)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.