Coding standard: return succ on failure?
Christian König
deathsimple at vodafone.de
Fri Aug 2 07:07:07 PDT 2013
I also agree that returning false on success is a pretty bad idea,
stumbled over that a couple of times, especially with AnalyzeBranch.
Christian.
Am 02.08.2013 15:30, schrieb Chad Rosier:
> +1 :)
>
> On Thu, Aug 1, 2013 at 6:55 PM, Eric Christopher <echristo at gmail.com
> <mailto:echristo at gmail.com>> wrote:
>
> FWIW this drives me crazy as well.
>
> -eric
>
> On Thu, Aug 1, 2013 at 1:25 PM, Chandler Carruth
> <chandlerc at google.com <mailto:chandlerc at google.com>> wrote:
> > I have lobbied in the past for doing away with returning false
> on success. I
> > continue to do so.
> >
> > There are parts of the Clang parser that do this consistently,
> but they are
> > increasingly few and far between. I consistently see new code
> being written
> > in both Clang and LLVM using false to mean failure and true to
> mean success,
> > so I think we should just admit that this is the de-facto
> standard for new
> > code going forward.
> >
> > That said, the last time I raised this question, Chris showed up
> to argue.
> > ;]
> >
> >
> > On Thu, Aug 1, 2013 at 10:20 AM, Shuxin Yang
> <shuxin.llvm at gmail.com <mailto:shuxin.llvm at gmail.com>> wrote:
> >>
> >> Hi, dear all:
> >>
> >> I find some of the code (e.g. LTOCodeGenerator) in llvm
> return false
> >> on succ (we might as well
> >> return 0 on succ as with many C code0); this is very confusing,
> >> counter-intuitive, and error-prone.
> >> Things are even worse, if this piece of code call other modules
> with
> >> negated logic.
> >>
> >> In what situation should we use this negated logic? Is it
> deprecated
> >> now? Can we toggle the logic
> >> to the way we would normally take for granted?
> >>
> >> Thanks in advance!
> >> A senior newbie (just brazenly promote myself)
> >> _______________________________________________
> >> llvm-commits mailing list
> >> llvm-commits at cs.uiuc.edu <mailto:llvm-commits at cs.uiuc.edu>
> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> >
> >
> >
> > _______________________________________________
> > llvm-commits mailing list
> > llvm-commits at cs.uiuc.edu <mailto:llvm-commits at cs.uiuc.edu>
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> >
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu <mailto:llvm-commits at cs.uiuc.edu>
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130802/d93a20b8/attachment.html>
More information about the llvm-commits
mailing list