Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #171053

Re: Corrupted C99 _Bool?

Show all headers | View raw

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> "das...@gmail.com" <dashley@gmail.com> writes:
>>>
>>>> C99 indicates that a _Bool is an unsigned integer type.  When a
>>>> variable of a type other than _Bool is assigned to a _Bool, C99
>>>> specifies that the _Bool receives the value of 0 if the variable was
>>>> 0, or 1 otherwise.
>>>>
>>>> But what does C99 say about a _Bool that is corrupted to a value other
>>>> than 0 or 1 (perhaps through a pointer error in another part of the
>>>> program)?  Will this corrupted _Bool still function correctly?
>>>>
>>>> For example:
>>>>
>>>> _Bool a = true;
>>>> _Bool b; /* Assume b is corrupted to "2" somehow */
>>>>
>>>> if (a && b)
>>>> {
>>>>    /* Would the compiler be able to use a bitwise */
>>>>    /* AND above, because it assumes all _Bools */
>>>>    /* must be 0 or 1, so that if (1 && 2) becomes */
>>>>    /* if (1 & 2) and evaluates false? */
>>>> }
>>>>
>>>> Thanks for any clarification.
>>>
>>> I'm reasonably sure that anything that would cause a _Bool object
>>> to have a value other than 0 or 1, or at least anything that tried
>>> to access such an object's value, would have undefined behavior.
>>
>> In C99 and also in C11, an implementation may define the type _Bool
>> to have a size of 1, a width of CHAR_BIT, and a representation that
>> matches the representation of unsigned char.  I'm not aware of any
>> implementation that makes these choices, but they are allowed under
>> the rules of the respective ISO C standards (assuming I didn't miss
>> something, but I'm reasonably sure that I didn't).
>
> As far as I can tell, gcc's behavior is consistent with that.

I expect that in fact gcc does not make this set of choices.  A
way of testing that is to compile this struct definition

    struct test_bool_width {
        _Bool  b : 8;  /* or probably any number > 1 */
    };

and see if gcc accepts it.  On my test system, gcc gives an
error for any width greater than 1.

>> Code running in such an implementation can easily store an object
>> representation, into a _Bool object, of an unsigned char with the
>> value 2.  Because the representations of _Bool and unsigned char
>> are the same, that is also the object representation of the value 2
>> considered as a _Bool object.
>>
>> After the store, reading the _Bool object (as a _Bool) is well
>> defined, and must produce the value 2, because of how object
>> representations are turned into values.  So, in such an
>> implementation, 'a && b' might not be the same as 'a & b',
>> even though no undefined behavior has occurred.
>
> C23 (as of the N3096 draft) resolves this by saying that:
>
>     The type bool shall have one value bit and (sizeof(bool)*CHAR_BIT)-1
>     padding bits.
>
> which means that if sizeof (bool) == 1 and a bool object's
> representation is all-bits-one, the value of that bool object is 1
> (true), since the (typically 7) padding bits do not contribute to the
> value.
>
> This program:
>
> #include <stdio.h>
> #include <string.h>
> int main(void) {
>     unsigned char c = -1;
>     _Bool b;
>     memcpy(&b, &c, 1);
>     printf("sizeof b = %zu, b = %d\n", sizeof b, b);
> }
>
> produces this output with gcc:
>
> sizeof b = 1, b = 255

Under C23 rules, this program must have had undefined behavior.
The reason is, if there were no undefined behavior, the _Bool
value of b must be either 0 or 1;  it cannot be anything else.
Ergo the padding bit values must have produced a non-value
representation, which accounts for the impossible value 255.

> C23 doesn't seem to specify whether the resulting representation of b is
> a non-value representation (previously "trap representation") or not.
> If a representation with any padding bits set to 1 is a non-value
> representation, then I *think* that the code has undefined behavior.
> (I'm assuming that compilers aren't expected to go to extra effort when
> converting *from* bool.)

The non-zero padding bits /can/ produce a non-value representation,
but they aren't required to.  Since the program produced an
impossible value, we know that there must have been undefined
behavior, and thus the non-zero padding bits must have resulted
in a non-value representation (since everything else is well
defined).

Note again that this conclusion is based on the C23 rules.  In
earlier versions of C this output is possible (as defined behavior)
if CHAR_BIT == 8 and the width of _Bool is also 8;  if the width of
_Bool is anything other than 8 then there must have been undefined
behavior (and as before the width of _Bool can be checked using
the struct bit-field definition method).

Disclaimer: I'm pretty sure all the above is right, but I didn't
re-check my statements as carefully as is my usual practice.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Corrupted C99 _Bool? "das...@gmail.com" <dashley@gmail.com> - 2023-07-11 17:32 -0700
  Re: Corrupted C99 _Bool? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-11 18:51 -0700
    Re: Corrupted C99 _Bool? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-11 19:13 -0700
    Re: Corrupted C99 _Bool? James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-07-12 02:47 -0400
    Re: Corrupted C99 _Bool? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-20 21:25 -0700
      Re: Corrupted C99 _Bool? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-21 01:58 -0700
        Re: Corrupted C99 _Bool? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-21 14:22 -0700
  Re: Corrupted C99 _Bool? David Brown <david.brown@hesbynett.no> - 2023-07-12 09:31 +0200
  Re: Corrupted C99 _Bool? Opus <ifonly@youknew.org> - 2023-07-12 22:10 +0200
    Re: Corrupted C99 _Bool? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-12 14:21 -0700
      Re: Corrupted C99 _Bool? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-20 22:17 -0700
    Re: Corrupted C99 _Bool? James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-07-12 18:44 -0400
      Re: Corrupted C99 _Bool? "das...@gmail.com" <dashley@gmail.com> - 2023-07-12 16:41 -0700
        Re: Corrupted C99 _Bool? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-07-13 01:17 +0100
        Re: Corrupted C99 _Bool? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-12 17:28 -0700
        Re: Corrupted C99 _Bool? David Brown <david.brown@hesbynett.no> - 2023-07-13 11:27 +0200
          Re: Corrupted C99 _Bool? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-13 15:18 -0700
            Re: Corrupted C99 _Bool? David Brown <david.brown@hesbynett.no> - 2023-07-14 09:07 +0200
            Re: Corrupted C99 _Bool? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-07-14 00:53 -0700
    Re: Corrupted C99 _Bool? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-20 22:09 -0700

csiph-web