[llvm-dev] [cfe-dev] Should functions returning bool return true or false on success?
David Blaikie via llvm-dev
llvm-dev at lists.llvm.org
Tue Sep 18 09:32:58 PDT 2018
On Tue, Sep 18, 2018 at 1:08 AM Hans Wennborg via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On Mon, Sep 17, 2018 at 7:57 PM, Nico Weber via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
> > Hi,
> >
> > in https://reviews.llvm.org/D52143 there's some uncertainty if LLVM code
> > prefers
> >
> > if (!Function())
> > // Call to function failed, deal with it
> >
> > or
> >
> > if (Function())
> > // Call to function failed, deal with it
> >
> > (Note that this is about functions returning bool, not int.)
> >
> > Folks on that review feel that returning true on success is probably
> what we
> > want, but it's not documented anywhere and we do have both forms in the
> > codebase.
> >
> > True on success seems more common:
> > http://llvm-cs.pcc.me.uk/?q=true+on+success
> > http://llvm-cs.pcc.me.uk/?q=true+on+error
> >
> > Does anyone have a pointer to previous on-list discussion on this? If
> not,
> > this thread could be the place where we sort this out once and for all
> :-)
>
> I don't remember on-list discussions about this, but I'd be curious to
> learn about the background.
>
> In particular, true-on-error seems pervasive in our various parsers,
> both in Clang and LLVM. Is this some parser writing convention that's
> also used outside LLVM, or why do we do this?
>
Nah, I believe it was an early LLVM convention (thought it was in the style
guide at some point - but perhaps it was just an undocumented norm that was
discussed from time to time) based on the idea that functions returning
integers on failure in C APIs used zero-on-success, non-zero-on-failure -
and the idea was that bool false-on-success, true-on-failure was consistent
with that.
- Dave
>
> Cheers,
> Hans
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180918/566bd61c/attachment.html>
More information about the llvm-dev
mailing list