Coding standard: return succ on failure?

[Christian König]

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>