Re: master 31544bc: Don’t convert pointer to bool

Re: master 31544bc: Don’t convert pointer to bool

[Stefan Monnier]

>     Without this patch, Oracle Studio 12.6 complains about converting
>     pointer to bool.

Is it right to complain or is that a bug in that tool?
To my naive intuition, it looks wrong since conversion to bool is
standard practice when doing `if (ptr) ...`.


        Stefan

Re: master 31544bc: Don’t convert pointer to bool

[Paul Eggert]

On 3/20/21 7:05 AM, Stefan Monnier wrote:
> Is it right to complain or is that a bug in that tool?
> To my naive intuition, it looks wrong since conversion to bool is
> standard practice when doing `if (ptr) ...`.

'bool b = ptr;' does not work in C89, and can be tricky in C++ as 
witness the now-deprecated "safe bool idiom", so there is some style 
caution here. Also, in my experience 'bool b = ptr;' is more likely to 
be a typo.

Since Emacs assumes C99-or-later this is just a style thing. Still, on 
the whole it seems that the "!!" is a win as it is obvious, consumes 
little room, and makes the unusual conversion clearer to the reader.

Re: master 31544bc: Don’t convert pointer to bool

[Matt Armstrong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>     Without this patch, Oracle Studio 12.6 complains about converting
>>     pointer to bool.
>
> Is it right to complain or is that a bug in that tool?
> To my naive intuition, it looks wrong since conversion to bool is
> standard practice when doing `if (ptr) ...`.

In code portable to pre-C99 the diff looks right to me.

Commit 31544bc was about assignment to "bool", not "if (ptr)...", and
the differece is relevant.

"if (ptr)..." and the like has always been valid C.  Instead, the
statememnts test the scalar expression against the zero value, which has
always well defined for pointers.

Essentially, in conditional statements there is an implicit "!= 0"
there.  There is no implicit "!= 0" when converting pointers to integral
types.

In older compilers without _Bool, "bool" usually devolves to char.

  void* p = ...;
  char c = p;

The above code has undefined behavior, since a pointer doesn't fit in a
char.  In practice, most compilers will generate code that assigns the
low order byte of p to b.  This can do things like set b zero for
non-zero pointers and set b to values outside [0, 1].

So, either of these are better:

  char c = !!p;
  char c = p ? true : false;