[llvm-dev] Counterintuitive use of LLVMBool in C-API?

[Alexander Benikowski via llvm-dev]

Of course, this is normal for C-APIs. But maybe change the name to
LLVMResult to propagate the real use? I am not arguing about the results
themself. They are standard. But the name is missguiding. As long as it's
consistent i know that i have to write an extra record operator in Delphi
to reflect this.

2016-09-12 11:11 GMT+02:00 David Chisnall <David.Chisnall at cl.cam.ac.uk>:

> On 12 Sep 2016, at 09:59, Alexander Benikowski via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> > I stumbled across the following:
> > /* Builds a module from the bitcode in the specified memory buffer,
> returning a
> > reference to the module via the OutModule parameter. Returns 0 on
> success. */
> > LLVMBool LLVMParseBitcode2(LLVMMemoryBufferRef MemBuf,
> > LLVMModuleRef *OutModule);
> > However in most scenarios i know, a Bool is something like
> > 0 = False
> > !0 = True
> >
> > In short: is it just me or is this really counterintuitive?
>
> It is counterintuitive, but it is also consistent with a lot of C APIs
> (including most of the standard library).  Returning 0 on success and
> non-zero on failure is a very common idiom in C.  The rationale is that you
> can write:
>
> int ret;
> if ((ret = some_function()))
>         // Error handling
>
> and that ret will contain a meaningful error code on return (the latter is
> missing when you use a boolean type).
>
> David
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160912/0a066548/attachment.html>