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

[Alexander Benikowski via llvm-dev]

Okay after translating the headers to Delphi, i found more inconsistencies:

> LLVMTypeRef LLVMFunctionType(LLVMTypeRef ReturnType,
>                              LLVMTypeRef *ParamTypes, unsigned ParamCount,
>                              LLVMBool IsVarArg);
>

In this case it is the other way around. 0 means False and anything else
means true :/ (so it acts more like a "traditional" bool)

2016-09-12 11:17 GMT+02:00 Alexander Benikowski <sebal007 at googlemail.com>:

> 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/20170918/b5934348/attachment.html>