[LLVMdev] C interface

[Gordon Henriksen]

On 2007-09-12, at 18:34, Chris Lattner wrote:

> On Sep 11, 2007, at 10:01 PM, Gordon Henriksen wrote:
>
>> I've attached the header, where I've mapped a portion of Module  
>> and most of Type and its subclasses. This is working, and I've  
>> built ocaml bindings on top of it.[1]
>
> Oooh, look at the long doubles ;-)

Oh, that's what this comment means:

     PackedStructTyID,///< 10: Packed Structure. This is for bitcode  
only

Maybe we can hide that better? ocaml mappings really (really really)  
like sequential enums with no dead values.

Oh well. I'll remap the values.

>> My naming conventions are similar to the Carbon interfaces in OS  
>> X. (Should I prefer a Unixy flavor instead?) Naming prefix is  
>> LLVM, which may be a bit long. (Would LL be better?)
>
> LLVM seems fine to me, and the naming convention seems ok (using  
> lowercase + underscores makes the name longer).  I do find things  
> like this slightly strange:
>
> /* Same as Module::addTypeName. */
> int AddTypeNameToModule(LLVMModuleRef M, const char *Name,
> LLVMTypeRef Ty);
>
> I'd expect it to be named something like "LLVMModuleAddTypeName" or  
> something, using NamespaceClassMethod uniformly.

I tried that at first; I do like to do Òmethod completion for CÓ in  
XCode by typing something like LLVMModule esc. Unfortunately, the  
names got bizarre and unreadable. I can go back to that, but it  
wasn't Ôdoing itÕ for me.

>> Pointers are opaque, obviously. I find myself copying enums, which  
>> is mildly scary.
>
> Copying the enums does seems scary. Is LLVMTypeKind that useful?

Uhm. Just a little bit important? :) I'll need to do the same thing  
with instructions kinds, too.

> Is there any way around this?

Well, we could move the enums into the C interfaces and include the C  
interfaces from the C++ code. That moves the values to the global  
namespace, though; neither Type::FooTyID nor llvm::Type::FooTyID  
would be valid. The types themselves can be typedef'd back where they  
belong.

>> I'm using C strings instead of const char*, size_t tuples. This  
>> avoids having to write things like "tmp", strlen("tmp") in C, and  
>> is well-supported for language bindings. Nevertheless, most  
>> languages other than C have binary-safe string types, so I'm  
>> certainly willing to have my mind changed if we want to prefer  
>> correctness over inconvenience to the C programmer. (Providing  
>> overloads is silly, though.)
>
> I think this makes sense.  In order to support arbitrary strings,  
> you could have a:
>
> void LLVMValueSetName(LLVMValueRef, const char *, unsigned len);
>
> ... function that works with arbitrary strings.

That's true for this case, but I'm not sure there's always a backdoor  
like that available. For some things it doesn't matter, of course;  
valid filenames can't contain '\0' on anything notable except Mac OS  
­ X, for one. I guess it's a case-by-case decision. While I'm sure  
someone, somewhere, would appreciate consistency, that person is not me.

>> I'm putting the headers in include/llvm-c. I created a new library  
>> called Interop to house the C bindingsÑbut it might make more  
>> sense to implement the C bindings in each library instead. They're  
>> just glue which the linker will trivially DCE, so that approach  
>> may have merit.
>
> Nice!  You'll make a lot of friends with this :)

:) Of course, you realize they won't be happy until they don't have  
to link using g++É

> adding the bindings to the libraries in question make sense.

I'll do that.

Ñ Gordon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070912/3272f009/attachment.html>