From 6121670144987639563 X-Google-Language: ENGLISH,ASCII X-Google-Thread: f78e5,c5e1f3188bfb5123 X-Google-Attributes: gidf78e5,public X-Google-Thread: 1149ec,c5e1f3188bfb5123 X-Google-Attributes: gid1149ec,public X-Google-ArrivalTime: 2000-11-01 12:29:07 PST Path: supernews.google.com!sn-xit-02!sn-xit-03!supernews.com!europa.netcrusader.net!195.92.193.196!diablo.theplanet.net!dispose.news.demon.net!demon!news.demon.co.uk!demon!mail2news.demon.co.uk!not-for-mail From: Team-Rocket@gmx.net (Niklas Matthies) Newsgroups: comp.std.c++,comp.std.c Subject: Re: C and C++ Standard incompatibility for signed character type Date: Wed, 1 Nov 2000 20:28:45 GMT Organization: Team Rocket Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: References: <39F254C8.510803FB@null.net> <8666mkbq7h.fsf@gabi-soft.de> X-Trace: mail2news.demon.co.uk 973110534 mail2news:218 mail2news mail2news.demon.co.uk X-Complaints-To: abuse@demon.net X-Mail2News-Path: news.demon.net!mulga.cs.mu.oz.au X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 User-Agent: slrn/0.9.6.2 (Linux) Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mulga.cs.mu.OZ.AU id HAA24311 Lines: 93 Xref: supernews.google.com comp.std.c++:1884 comp.std.c:1535 On Wed, 1 Nov 2000 19:13:56 GMT, Francis Glassborow wrote: > In article , > Niklas Matthies writes > >Trap values are a property of the type. A trap value of type T only > >causes undefined behavior when accessed through an lvalue of type T. I= f > >an object ("object" in the sense that the C standard uses) of type T1 = is > >accessed through an lvalue of type T2, then it doesn't matter whether > >the bit pattern of the object constitutes a trap representation of typ= e > >T1, it only matters whether it constitutes a trap representation of ty= pe > >T2 (the type through which it is accessed). So, since unsigned char do= es > >not have trap values, it is of course absolutely valid to access chars > >as unsigned chars. >=20 > There is a requirement that the range of values for char shall either b= e > that of signed char or that for unsigned char. Any trap value could no= t > be in that range. So the question is 'Can a signed char include trap > values? I guess the answer to that may be 'yes' but I am uncertain. > CHAR_BIT give the number of bits in the smallest object that is not a > bit-field. It would be a very unusual implementation in which unsigned > char had more bits than CHAR_BIT, indeed I am not convinced that that i= s > allowed. A char object consists of value bits, possibly a sign bit (if it is signed), and possibly padding bits (if it signed). CHAR_BIT counts all those bits, including the padding bits. Quoting some relevant bits from [C99:6.2.6.1] and [C99:6.2.6.2]: Values stored in unsigned bit-fields and objects of type unsigned char shall be represented using a pure binary notation. Values stored in non-bit-field objects of any other object type consist of /n/ =D7 CHAR_BIT bits, where /n/ is the size of an object of that type, in bytes. The value may be copied into an object of type unsigned char [/n/] (e.g., by memcpy); the resulting set of bytes is called the /object representation/ of the value. [=B7=B7=B7] Two values (other th= an NaNs) with the same object representation compare equal, but values that compare equal may have different object representations. [=B7=B7=B7] For signed integer types, the bits of the object representation shall be divided into three groups: value bits, padding bits, and the sign bit. There need not be any padding bits; there shall be exactly one sign bit. Each bit that is a value bit shall have the same value as the same bit in the object representation of the corresponding unsigned type (if there are /M/ value bits in the signed type and /N/ in the unsigned type, then /M/ <=3D /N/). If the sign bit is zero, it shall not affect the resulting value. If the sign bit is one, the value shall be modified in one of the following ways:=20 - the corresponding value with sign bit 0 is negated (/sign and magnitude/); - the sign bit has the value -(2^/N/) (/two's complement/); =20 - the sign bit has the value -(2^/N/ - 1) (/one's complement/). Which of these applies is implementation-defined, as is whether the value with sign bit 1 and all value bits zero (for the first two), or with sign bit and all value bits 1 (for one's complement), is a trap representation or a normal value. In the case of sign and magnitude and one s complement, if this representation is a normal value it is called a negative zero. The values of any padding bits are unspecified. A valid (non-trap) object representation of a signed integer type where the sign bit is zero is a valid object representation of the corresponding unsigned type, and shall represent the same value. The precision of an integer type is the number of bits it uses to represent values, excluding any sign and padding bits. The width of an integer type is the same but including any sign bit; thus for unsigned integer types the two values are the same, while for signed integer types the width is one greater than the precision. -- Niklas --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.research.att.com/~austern/csc/faq.html ] [ Note that the FAQ URL has changed! Please update your bookmarks. ]