Alexander Benikowski via llvm-dev
2016-Sep-12 09:17 UTC
[llvm-dev] Counterintuitive use of LLVMBool in C-API?
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>
Alexander Benikowski via llvm-dev
2017-Sep-18 18:43 UTC
[llvm-dev] Counterintuitive use of LLVMBool in C-API?
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>