From owner-sc22wg14@open-std.org Thu Mar 13 02:13:26 2008 Return-Path: X-Original-To: sc22wg14-domo1 Delivered-To: sc22wg14-domo1@open-std.org Received: by open-std.org (Postfix, from userid 521) id 7016BD84A5; Thu, 13 Mar 2008 02:13:26 +0100 (CET) X-Original-To: sc22wg14@open-std.org Delivered-To: sc22wg14@open-std.org X-Greylist: delayed 367 seconds by postgrey-1.18 at pingo.cv.ihk.dk; Thu, 13 Mar 2008 01:13:25 UTC Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by open-std.org (Postfix) with ESMTP id 5AF9938511 for ; Thu, 13 Mar 2008 02:13:10 +0100 (CET) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 12 Mar 2008 18:06:36 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.25,491,1199692800"; d="scan'208";a="217968894" Received: from azsmsx602.amr.corp.intel.com ([10.2.121.201]) by azsmga001.ch.intel.com with ESMTP; 12 Mar 2008 18:06:36 -0700 Received: from azsmsx501.amr.corp.intel.com ([10.2.167.99]) by azsmsx602.amr.corp.intel.com ([10.2.121.201]) with mapi; Wed, 12 Mar 2008 18:06:35 -0700 From: "Nelson, Clark" To: ISO C Date: Wed, 12 Mar 2008 18:06:36 -0700 Subject: Signed char and padding bits Thread-Topic: Signed char and padding bits Thread-Index: AciEpnxOnED4TJKHSey+kzJSXsZ4nw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-sc22wg14@open-std.org Precedence: bulk The standard is pretty clear that unsigned char can't have any padding bits= . However, according to 6.2.6.2p2, signed integer types (conspicuously not = excluding signed char) can have padding bits. So far so good. Now consider 6.5p6 (effective type), especially the -->>emphasized<<-- phra= se: If a value is copied into an object having no declared type using memcpy or= memmove, -->>or is copied as an array of character type<<--, then the effe= ctive type of the modified object for that access and for subsequent access= es that do not modify the value is the effective type of the object from wh= ich the value is copied, if it has one. "Character type" includes signed char, of course, which may (apparently) ha= ve padding bits. And since the values of padding bits are unspecified, they= presumably need not be copied along with a signed char value. Putting all these things together, I can see only two possibilities. (1) If signed char has padding bits, then the padding bits of a signed char= must be padding bits in the object representation of every other type (oth= er than unsigned char, of course). Because if those bits were part of the v= alue representation of any other type, then copying an object as an array o= f signed char would not necessarily copy all the significant bits, and ther= efore wouldn't be guaranteed to work. (2) Alternatively, there is an inconsistency in the C99 standard. I'm soliciting opinions as to which of these interpretations is correct. For background, this issue came to my attention from consideration of a C++= committee issue (file:///C:/Documents%20and%20Settings/cnelson1/My%20Docum= ents/j16/cwg_active.html#240), at least partly about whether accessing an u= ninitialized variable of type unsigned char should give undefined behavior. The C++ standard says that "For character types, all bits of the object rep= resentation participate in the value representation. For unsigned character= types, all possible bit patterns of the value representation represent num= bers." So the status of unsigned char is the same in C and C++. But in C++,= a signed char is allowed to have trap representations, but not any padding= bits. The question arises whether that should also be true of C. Clark