Assignment to _Bool bitfields
Kevin Bracey
_Bool, or in the same way as an assignment to a normal integer?
For example, does:
#include <stdio.h>
int main()
{
struct { _Bool a:1; } bf;
bf.a = &main;
printf("bf.a\n", bf.a);
}
have to print 1 without diagnostics?
The sections in question state:
6.3.1.2: When any scalar value is converted to _Bool, the result is 0
if the value compares equal to 0; otherwise the result is 1.
6.7.2.1.9: A bit-field is interpreted as a signed or unsigned integer
type consisting of the specified number of bits. If the
value 0 or 1 is stored into a nonzero-width bit-field of
type _Bool, the value of the bit-field shall compare equal to
the value stored.
Given that _Bool is an "unsigned integer type", I can't see that this
pins it down either way. The last sentence of 6.7.2.1.9 would seem to
imply that one can might store numbers other than 0 or 1 in the bitfield,
implying it acts like an int, but I'm not sure.
--
Kevin Bracey, Principal Software Engineer
Pace Micro Technology plc Tel: +44 (0) 1223 518566
645 Newmarket Road Fax: +44 (0) 1223 518526
Cambridge, CB5 8PB, United Kingdom WWW: http://www.pace.co.uk/
Keith Thompson
> Is assignment to a _Bool bitfield treated the same way as assignment to
> _Bool, or in the same way as an assignment to a normal integer?
>
> For example, does:
>
> #include <stdio.h>
>
> int main()
> {
> struct { _Bool a:1; } bf;
> bf.a = &main;
> printf("bf.a\n", bf.a);
> }
>
> have to print 1 without diagnostics?
Actually, it prints the string "bf.a" followed by a newline, then
returns an unspecified exit status.
I don't usually jump on typos, but in this case it might matter
whether the format is "bf.a = %d\n" or "bf.a = %u\n". (I'm too lazy
to figure out whether and how it matters.)
Time spent compiling and running code before you post it, especially
to a newsgroup as picky as this one, is seldom wasted.
--
Keith Thompson (The_Other_Keith) k...@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Clive D. W. Feather
<kevin....@pace.co.uk> writes
>Is assignment to a _Bool bitfield treated the same way as assignment to
>_Bool, or in the same way as an assignment to a normal integer?
> struct { _Bool a:1; } bf;
> bf.a = &main;
Oh *boy*. Someone the other day was asking whether it matters whether or
not bit-fields have a separate type or not, and here comes a perfect
example out of nowhere.
I don't even know for sure whether or not that line is legitimate or
violates a constraint. Let's see:
6.7.2.1:
[#4] 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.
That implies that the type of bf.a is _Bool, the assignment is legal and
produces the value 1.
But:
[#9] A bit-field is interpreted as a signed or unsigned
integer type consisting of the specified number of
bits.104)
So a bit-field is a signed or unsigned integer type with some number of
bits. That means, I *think*, that bf.a is not the type _Bool and the
assignment violates a constraint.
It then goes on to say:
If the value 0 or 1 is stored into a nonzero-
width bit-field of type _Bool, the value of the bit-field
shall compare equal to the value stored.
So the bit-field can have the type _Bool, but the behaviour is undefined
if you don't store 0 or 1 in it. But on the fourth (I think) hand, the
right operand of assignment is converted to the type of the left operand
(ignoring qualifiers) before assignment, so it *isn't* undefined because
the value *will* be 0 or 1.
You know, I could accept that bit-fields *weren't* a separate type, were
it not for the fact that that alters how they go through the integer
promotions. And you can't just fix those, because there are knock-on
effects for things like:
struct { unsigned int uf : 3; } s;
int x;
x = s.uf = -1;
--
Clive D.W. Feather, writing for himself | Home: <cl...@davros.org>
Tel: +44 20 8371 1138 (work) | Web: <http://www.davros.org>
Fax: +44 870 051 9937 (NOTE CHANGE) | Work: <cl...@demon.net>
Written on my laptop; please observe the Reply-To address
Douglas A. Gwyn
I think what was intended is "shall be declared using a type".
Wojtek Lerch
> Kevin Bracey <kevin....@pace.co.uk> writes:
...
> > #include <stdio.h>
> >
> > int main()
> > {
> > struct { _Bool a:1; } bf;
> > bf.a = &main;
> > printf("bf.a\n", bf.a);
> > }
> Actually, it prints the string "bf.a" followed by a newline, then
> returns an unspecified exit status.
No, its exit status is zero:
5.1.2.2.3 Program termination
1 If the return type of the main function is a type compatible with
int, a return from the initial call to the main function is equivalent
to calling the exit function with the value returned by the main
function as its argument; reaching the } that terminates the main
function returns a value of 0.
Kevin Bracey
So what does it mean for a bit-field to be declared as type _Bool?
There is one explicit statement:
If the value 0 or 1 is stored into a nonzero-
width bit-field of type _Bool, the value of the bit-field
shall compare equal to the value stored.
But that's no different to a bit-field of type unsigned int.
So either it's just a notational convenience, or it's supposed to actually
behave like _Bool for conversion purposes. Surely someone here knows what the
intent was?
--
Kevin Bracey
http://www.bracey-griffith.freeserve.co.uk/
Keith Thompson
> Keith Thompson <k...@cts.com> wrote in message
> news:<yecznzu...@king.cts.com>...
> > Actually, it prints the string "bf.a" followed by a newline, then
> > returns an unspecified exit status.
>
> No, its exit status is zero:
>
> 5.1.2.2.3 Program termination
>
> 1 If the return type of the main function is a type compatible with
> int, a return from the initial call to the main function is equivalent
> to calling the exit function with the value returned by the main
> function as its argument; reaching the } that terminates the main
> function returns a value of 0.
You're right. In C90, the exit status is unspecified. In C99, it's
0. I forgot that they had changed that. (Personally, I wasn't
entirely happy with the change; it caters to sloppy coding habits.)
Douglas A. Gwyn
> I forgot that they had changed that.
Primarily, to legitimatize the early examples in K&R.
I didn't like it either.
Tony Finch
That's absurd, since the early examples aren't valid any more because
they rely on implicit int.
Tony.
--
f.a.n.finch <d...@dotat.at> http://dotat.at/
SOUTHEAST ICELAND: NORTHEAST BACKING NORTHWEST 5 INCREASING 6 TO GALE 8. RAIN
AND SNOW. MODERATE.
larry...@sdrc.com
>
> So either it's just a notational convenience, or it's supposed to actually
> behave like _Bool for conversion purposes. Surely someone here knows what the
> intent was?
The intent is that it behave like _Bool.
-Larry Jones
I think grown-ups just ACT like they know what they're doing. -- Calvin
Douglas A. Gwyn
> That's absurd, ...
Tough, the fact remains.