Coding standard: return succ on failure?

Chad Rosier chad.rosier at gmail.com
Mon Aug 5 14:33:59 PDT 2013


On Fri, Aug 2, 2013 at 1:06 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote:

>
> On Aug 2, 2013, at 6:30 AM, Chad Rosier <chad.rosier at gmail.com> wrote:
>
> > +1 :)
>
> Wait, did you mean ‘+0'?


Haha.. BOO!!


>
> /jakob
>
> > On Thu, Aug 1, 2013 at 6:55 PM, Eric Christopher <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>
> 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>
> 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
> > >> 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
> > >
> > _______________________________________________
> > llvm-commits mailing list
> > 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/20130805/1b159465/attachment.html>


More information about the llvm-commits mailing list