[LLVMdev] C interface
gordonhenriksen at mac.com
Wed Sep 12 19:10:59 CDT 2007
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.
> Oooh, look at the long doubles ;-)
Oh, that's what this comment means:
PackedStructTyID,///< 10: Packed Structure. This is for bitcode
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
>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the LLVMdev