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

Groups > comp.lang.c > #171024

Re: Corrupted C99 _Bool?

Show all headers | View raw

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.

> 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

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.)

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

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