[llvm-dev] Counterintuitive use of LLVMBool in C-API?
Alexander Benikowski via llvm-dev
llvm-dev at lists.llvm.org
Mon Sep 12 02:17:45 PDT 2016
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).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev