[Bug c/80730] bogus initializer element is not computable at load time converting a string to bool

["msebor at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80730

--- Comment #5 from Martin Sebor <msebor at gcc dot gnu.org> ---
I"m not sure I understand what you're saying.  Your comment that "the
initializer *as 
converted* must be a constant expression (and, thus, to be an address 
constant, must be of pointer type)" makes it sound as an argument for rejecting
'_Bool b = "";' which would mean that you think '_Bool b = a;' should be
rejected as well.  But your other comment that you'd "consider it appropriate
to handle implicit conversions in initializers exactly the same as casts are
handled" sounds as though you think '_Bool b = "";' should be accepted (because
'_Bool b = (_Bool)"";' is accepted).  So I'm not sure what to make of it.

The point I am trying to make is that the GCC behavior, besides being
inconsistent, is not friendly or useful, no mater how one interprets the intent
of the standard.  Taking the three cases:

  _Bool b0 = "";    // rejected by GCC with an error
  _Bool b1 = !"";   // accepted by GCC without a warning

  const char a[] = "";
  _Bool b2 = a;     // accepted with -Waddress

in each the initializer is the result of converting an address constant to
_Bool.

IBM XLC and Oracle c99 warn on the first and third and reject the second with
an error.  That's just as unhelpful as what GCC does.

Clang, ICC, and even Visual C, accept all three (Clang issues
-Wpointer-bool-conversion for the third, the other two are silent).  That's
much better.

The most useful behavior is to accept all three with a pedantic warning.  It
makes it easy to port code to GCC that was written to one of these compilers,
while also making it possible to find out about portability problems when
porting to other compilers.  Do you agree with this as a goal to work toward?