From owner-sc22wg14@open-std.org Tue Apr 18 21:38:52 2006 Return-Path: X-Original-To: sc22wg14-domo Delivered-To: sc22wg14-domo@open-std.org Received: by open-std.org (Postfix, from userid 521) id 0954F216B4; Tue, 18 Apr 2006 21:38:52 +0200 (CET DST) X-Original-To: sc22wg14@open-std.org Delivered-To: sc22wg14@open-std.org Received: from sov-mail-b0013.gradwell.net (sov-mail-b0013.gradwell.net [193.84.87.37]) by open-std.org (Postfix) with ESMTP id 5F5EF21699 for ; Tue, 18 Apr 2006 21:38:49 +0200 (CET DST) Received: from digraph.polyomino.org.uk ([81.187.227.50] ident=postmaster&pop3$polyomino&org*uk) by sov-mail-b0013.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.214) id 44454048.4f72.20f for sc22wg14@open-std.org; Tue, 18 Apr 2006 20:38:48 +0100 (envelope-sender ) Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.52) id 1FVw2C-0001tg-0Q for sc22wg14@open-std.org; Tue, 18 Apr 2006 19:38:48 +0000 Date: Tue, 18 Apr 2006 19:38:48 +0000 (UTC) From: "Joseph S. Myers" X-X-Sender: jsm28@digraph.polyomino.org.uk To: wg14 Subject: Re: (SC22WG14.11089) DR #315 example In-Reply-To: <20060405142731.236D32367A@open-std.org> Message-ID: References: <20060331134224.AA587236A1@open-std.org> <20060404155335.E065F216C0@open-std.org> <20060405142731.236D32367A@open-std.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-sc22wg14@open-std.org Precedence: bulk On Wed, 5 Apr 2006, Derek M Jones wrote: > Clive, > > > > The addition, x.bf1+x.bf2, is performed, by gcc, using 37 bit unsigned > > > long long arithmetic. > > > > My reading of DRs 120 and 122 is that we decided that a bit-field had its > > own type, it wasn't just a variant of an existing type. > > If we did, this intent is not reflected in the wording of C99. I believe the intent is reflected in the *textual history*, although the text on its own is unclear in both C90 and C99. C90 6.5.2.1: The expression that specifies the width of a bit-field shall be an integral constant expression that has nonnegative value that shall not exceed the number of bits in an ordinary object of compatible type. If the value is zero, the declaration shall have no declarator. C99 6.7.2.1, before TC2: [#3] The expression that specifies the width of a bit-field shall be an integer constant expression that has nonnegative value that shall not exceed the number of bits in an object of the type that is specified if the colon and expression are omitted. If the value is zero, the declaration shall have no declarator. (The changes in TC2 are irrelevant.) Note the change from "of compatible type" to "of the type that is specified if the colon and expression are omitted". This could be an attempt to make the readings of DR#015, 120, 122 clearer from the standard - but not an attempt carried through consistently to all other relevant text. Both C90 and C99 also say that "A bit-field is interpreted as [an integral|a signed or unsigned integer] type consisting of the specified number of bits.", both suggesting separate types. C90 says "A bit-field shall have a type that is a qualified or unqualified version of one of int, unsigned int, or signed int."; C99 says "A bit-field shall have a type that is a qualified or unqualified version of _Bool, signed int, unsigned int, or some other implementation-defined type.", both suggesting the bit-field has the underlying type instead of the new type. The responses to DR#015 and DR#122 say that an unsigned:1 bit-field promotes to int, not unsigned int. There is no special text in C90 or C99 to implement this; it relies on "If an int can represent all values of the original type" being applied to a special bit-field type. If bit-fields are no longer to have special types, then special wording like that in C++ [conv.prom]#3 is needed to preserve the promotion rules. (Note also that in C++ a long:3 bit-field promotes to int, not long; the proposed DR response would have it promote to long in C.) DR#120 points out that the only definition of the semantics of assignment to and initialization of bit-fields by values that aren't exactly representable is the normal definition of type conversion applied to special bit-field types. Without special types, what says that storing 2 in an unsigned:1 bit-field yields 0 (taking the least significant bit) rather than 1 (taking the next bit)? Suppose converting out-of-range integer values to signed integers produces a signal; must storing 2 in a signed int:1 bit-field nevertheless not produce a signal because 2 is within range for signed int? Must storing 256.0 in an int:1 bit-field store 0 rather than yielding undefined behavior? The DR response says "if int:7 were a type that is different from int, then these rules [6.3.1.1] would not apply to any bit-field type". On the contrary, they would apply to such types by virtue of them having their own integer conversion ranks: int:7 would have rank less than that of int. (The bullet point "A bit-field of type _Bool, int, signed int, or unsigned int." would be redundant but harmless; "type" could be taken as meaning "declared type" in this context and that of 6.7.2.1#4.) -- Joseph S. Myers jsm@polyomino.org.uk