C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Require diagnostic for array to bool conversion

From: Lénárd Szolnoki <cpp_at_[hidden]>
Date: Sat, 22 Jul 2023 11:02:55 +0100
Hi,

On Sat, 2023-07-22 at 10:35 +0100, Jonathan Wakely wrote:
>
>
> On Sat, 22 Jul 2023, 10:08 Lénárd Szolnoki via Std-Proposals,
> <std-proposals_at_[hidden]> wrote:
> > Hi,
> >
> > On Sat, 2023-07-22 at 11:42 +0300, sasho648 via Std-Proposals
> > wrote:
> > > I think a solution will be to outright ban such a conversion -
> > > where
> > > an lvalue array to pointer conversion will not be allowed in
> > > context
> > > where bool is expected.
> >
> > I agree that it's not ideal, but there are a lot of existing code
> > that
> > relies on the conversion of string literals to true. Mainly in the
> > form
> > of:
> >
> > assert(condition && "explanation");
>
>
> Would this work if we made arrays contextually convertible to bool?

Good idea, this works.

> I can't think of any other valid uses for "is this array a null
> pointer? No of course it isn't" (and this one is a bit of a "clever"
> hack anyway).

I agree that it's on the clever side, but it's working around a real
shortcoming of assert. Maybe assert could be improved to accept an
optional explanation. But this doesn't help with not breaking existing
code, where this seemingly grew into a possibly questionable idiom.

An alternate idiom could have used the comma operator to discard the
"explanation", but I never saw that one being used. Probably needs
extra parenthesis as well to play well with the assert macro.

> >
> > https://codesearch.debian.net/search?q=assert%28.*%26%26+*%22.*%22%29&literal=0
> >
> > C compatibility should also be considered.
> >
> > clang seems to have -Wstring-conversion that finds this problematic
> > conversion, it also seems to exclude the assert use case.
> >
> > Cheers,
> > Lénárd
> >
> > >
> > > On Sat, Jul 22, 2023 at 11:39 AM sasho648 <sasho648_at_[hidden]>
> > > wrote:
> > > >
> > > > int arr[2];
> > > > bool test = arr;
> > > > bool teststr = "string";
> > > >
> > > >
> > > > Which I came across while having a function like this:
> > > >
> > > > void set_property(const char *name, const char *default_value);
> > > > void set_property_bool(const char*name, bool default_value);
> > > >
> > > > Where I thought the bool one was expecting a string as second
> > > > argument as well and so I wrote:
> > > >
> > > > set_property_bool("test", "true");
> > > >
> > > > Which compiled fine and even worked until I decided to change
> > > > it
> > > > to:
> > > >
> > > > set_property_bool("test", "false");
> > > >
> > > > In my opinion such a conversion holds no value - since it has
> > > > only
> > > > one outcome - and furthermore I think it's against C++ type
> > > > safety
> > > > - and even furthermore I think currently it's only purpose is
> > > > obfuscation contests or creating hard to diagnose bugs as the
> > > > case
> > > > I've shown above.
> >

Received on 2023-07-22 10:03:00