From 1007875512474458044 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1149ec,c5e1f3188bfb5123 X-Google-Attributes: gid1149ec,public X-Google-Thread: f78e5,c5e1f3188bfb5123 X-Google-Attributes: gidf78e5,public From: wmm@fastdial.net Subject: Re: C and C++ Standard incompatibility for signed character type Date: 2000/10/16 Message-ID: <8sernp$8d3$1@nnrp1.deja.com>#1/1 X-Deja-AN: 682099549 Approved: Fergus Henderson , moderator of comp.std.c++ References: X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Http-User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt) X-Complaints-To: abuse@demon.net X-Mail2News-Path: news.demon.net!mulga.cs.mu.oz.au X-Trace: mail2news.demon.co.uk 971711343 mail2news:8111 mail2news mail2news.demon.co.uk X-Http-Proxy: 1.1 x56.deja.com:80 (Squid/1.1.22) for client 205.181.152.41 Organization: Deja.com - Before you buy. X-Article-Creation-Date: Mon Oct 16 12:19:09 2000 GMT X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-MyDeja-Info: XMYDJUIDwmmj16 Newsgroups: comp.std.c++,comp.std.c In article , Jack Klein wrote: > Both the C99 (ISO 9899:1999) and C++ (ISO 14882:1998) are claimed to > be compatible with the original ISO C standard in terms of the > original integral types (char, short, int, long), although these > claims are not in the standards and not normative. > > Both purport that descriptions of padding bits and trap > representations were allowed, just not documented, in ISO C 90. > > But there is one discrepancy: > > C++ 1998 3.9.1 paragraph 1: > > ===== > For character types, all bits of the object representation participate > in the value representation. For unsigned character types, all > possible bit patterns of the value representation represent numbers. > These requirements do not hold for other types. > ===== > > This rules out padding bits in signed char, but permits trap > representations. > > C99 6.2.6.2 paragraph 2: > > ===== > [#2] 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. > ===== > > There is specifically no contrary wording for signed char, so under > this standard signed char can have both padding bits and trap > representations. > > The issue is: > > If both standards are intended to be compatible with C90, one of must > be incorrect. Signed char cannot both have and not have padding bits. > > The questions are: > > Are the two standards intentionally, or inadvertently, incompatible? > > If they are intentionally incompatible, is this a difference in a > fundamental type that we truly want between C and C++? > > If they are inadvertently incompatible and such a difference is not > wanted, which is incorrect? > > Should signed char: > > 1. Be different between C and C++? > > 2. Allow padding bits in both languages? > > 3. Disallow padding bits in both languages? I can't speak definitively for either version of C. However, I do know the background of that specification in C++, and it was our understanding that we were simply making explicit what was intended and understood to be the specification in C89. The main reason for specifying the character types that way was to allow something like strcpy to be written in well-defined C++, with no magic required. You need a type that can both access all bits of memory and not trap on any bit patterns. We could have invented a "byte" type for that purpose, but we felt (and were assured by J11 people participating in J16) that the C standard intended that unsigned char have the needed properties. I won't speculate as to either the implications or the rationale of the C99 specification in this regard. -- William M. Miller, wmm@fastdial.net Vignette Corporation (www.vignette.com) Sent via Deja.com http://www.deja.com/ Before you buy. --- [ 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. ]