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

Groups > comp.lang.c > #170701

Re: Corrupted C99 _Bool?

Show all headers | View raw

Opus <ifonly@youknew.org> writes:

> On 12/07/2023 02:32, das...@gmail.com wrote:
>> 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?
>> 
>
> It's undefined behavior. Just like if you corrupt any value of any
> other type.
>
>> 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.
>
> If the memory holding a _Bool value gets corrupted, there is obviously
> no way for the compiler to automatically correct it. How would it?
>
> It's UB, but the practical result will of course depend on the
> target. A _Bool is held by an integer under the hood in practice.
>
> Compilers do force a value of 1 for any value other than 0 assigned to
> it *during assignment*, and 0 otherwise. But again, only when an 
> assignment occurs (or a cast).

More precisely, *conversion* from any scalar type to _Bool yields a
value of 0 if the converted value is 0, 1 otherwise.  Assignment
performs an implicit conversion; so do argument passing, initialization,
and a return statement.  And of course a cast performs an explicit
conversion.

> For instance, the expression '(int)(_Bool) 5' yields 1.
>
> But if you alias a _Bool, say:
>
> _Bool b;
>
> *(int *) &b = 5;
>
> While UB, in practice in most implementations, b will be represented
> internally as an int and here will hold the value 5. Not 1.

_Bool is most likely smaller than int, so the assignment is likely to
clobber bytes not belonging to the _Bool object.

> This would cause a problem if you expect the value to be either 0 or 1
> exclusively. For instance if you cast it back to an int and do some 
> artihmetic or bitwise operations with that.
>
> Regarding what would happen to '(a && b)' in your example, the '&&'
> operator is NOT a bitwise operator. Even when dealing strictly with 
> _Bool's on each side of the operator, it can't be implemented with a
> bitwise operation when compiled. Quoting the standard regarding the
> '&&' operator:
>
> "The && operator shall yield 1 if both of its operands compare unequal
> to 0; otherwise, it yields 0. The result has type int.
> Unlike the bitwise binary & operator, the && operator guarantees left
> to-right evaluation;
> if the second operand is evaluated, there is a sequence point between
> the evaluations of the first and second operands. If the first operand 
> compares equal to 0, the second operand is not evaluated."

Yes, but if a and b are both of type _Bool, the compiler can assume that
they both have a value of 0 or 1.  If that assumption is valid (and if a
and b are not volatile), then `a & b` and `a && b` yield the same value.
If the assumption is not valid, then the behavior of `a && b` is
undefined.

A compiler *can* implement `a && b` as `a & b` if both are of type _Bool
and neither is volatile.

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