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

Groups > comp.lang.c > #170705

Re: Corrupted C99 _Bool?

Show all headers | View raw

"das...@gmail.com" <dashley@gmail.com> writes:
> On Wednesday, July 12, 2023 at 6:45:06 PM UTC-4, James Kuyper wrote:
>> An implementation could generate code for every access through an lvalue 
>> of type _Bool that is equivalent to retrieving an integer value from 
>> that location and then doing the equivalent of !!val, or val&1, or any 
>> other operation that maps 0 to 0 and 1 to 1, and maps every valid 
>> integer value to one of those two values. 
>> 
>> Implementations are not required to do that, which is what makes such 
>> code dangerous. However, they are permitted to that, which is what would 
>> make is possible for the code to be safe with a particular implementation.
>
> Thanks for the informative replies.  Opus' interpretation comes the
> closest to how I read the C99 standard, but James Kuyper's reply comes
> closest to how I think about the problem (as mapping).
>
> I often see code like this:
>
> typedef unsigned char boolean;
> boolean a = FALSE;
> boolean b = TRUE;
> a = 42;  //Oops, some other part of the program used an uninitialized pointer.
> if ((a == FALSE) && (b == TRUE)) ...
>
> The problem I have with the tests against FALSE and TRUE is that there
> are 254 values that are neither FALSE nor TRUE.  This is an
> "equivalence classing" or "mapping" problem.  Every possible bit
> pattern has to behave as if it is FALSE or TRUE.

Presumably FALSE and TRUE are #defined as 0 and 1, respectively.

This "boolean" type is not _Bool.  It has (typically) 8 value bits and
256 distinct values, all equally valid.

Like any scalar type, if you use a value of this type as a condition,
it's treated as false if it compares equal to 0, true otherise.

It's common in pre-1999 C to use some integer type (char, unsigned
char, int) as a logically boolean type.  You have to be aware that
the compiler doesn't assign any meaning to the fact that you named it
"boolean".

I use _Bool if at all possible, but if I can't assume it's available, I
like:

    typedef enum { false, true } bool;

But again, an object of this enumerated type has at least 256 distinct
values, and I need to avoid assigning values other than false or true.

One option is to carefully write your code so that no value other than 0
or 1 is ever stored in an object of your pseudo-boolean type -- but
that's very ndifficult to do consistently, and the compiler will not
warn you if you make a mistake.

A better option is to avoid using any operations that care which
non-zero value an object of your type has.  *Never* compiler a logically
boolean value for equality or inequality to FALSE or TRUE.  Don't write
`if (a == FALSE && b == TRUE)`; write `if (!a && b)`.

> One solution is this:  if (!a && b) ...
>
> Another solution is: if ((a == FALSE) && (b != FALSE)) ...

It happens that comparison to FALSE is safer than comparison to TRUE,
but the comparison is unnecessary clutter.

> So, back to my original post ...
>
> SOUGHT GUARANTEE: I'm only looking for one guarantee: for a given
> improper (corrupted) value of a _Bool on a given platform, it will
> always test as if it is logically false or logically true.  In other
> words, the compiler can't use methods that would result in a value of
> 42 testing as false in one place and true in another.  This is
> ultimately a mapping or equivalence-classing requirement.  All bit
> patterns would have to map to false or true.
>
> Do I have this guarantee?

No, you absolutely do not have this guarantee.  If you've managed to
store a value other than 0 or 1 in a _Bool object, any use of that value
has undefined behavior.  Just don't.

> And the followup question would be, in the event of corruption, what
> happens if you do any of these things?
>
> if (a == b) ...
> if (a == false) ...
> if (a == true) ...

Undefined behavior -- and at least for the 2nd and 3rd lines, rejection
in a code review.

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