Counterintuitive use of LLVMBool in C-API?


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).


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.

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 :confused: (so it acts more like a “traditional” bool)