I've updated the header (enclosed).

On Feb 24, 2008, at 11:24 PM, Evan Cheng wrote:> 1. __LTO__ -> LLVM_C_LTO
> 3. Rather than using underscore in function names, e.g. lt_foo_bar,
> use capital letters and also start with prefix LLVM. e.g.
> LLVMLTOFooBar.
As we discussed, this is interface is llvm independent. It may even
migrate out of include/llvm-c at some point.
> 2. Do we need those #include's?
We need stddef.h for size_t and stdbool.h for bool.
> 4. lto_codegen_release -> lto_codegen_release_memory to be clearer
> and more consistent.
Renamed to lto_codegen_dispose()
> 5. Use C comments /* ... */?
Fixed.
> 6. Please start comments with capital letters and end sentences
> with periods! Or perhaps not since it'll drive Chris nuts. :-)
Fixed.
On Feb 24, 2008, at 6:10 PM, Gordon Henriksen wrote:>> #include <stdint.h>
>> #include <stdbool.h>
>
> Note that MSVC++ still doesn't support C99, and is a target for
> LLVM. I'd suggest bool -> int and uint8_t* -> void* to resolve
the
> dependency.
I've change all the uint8_t to void. I'm going to leave the use of
bool. The implementation of lto is all in C++, so it will build with
MSVC++. The only thing that might get tripped up by the use of bool
in the interface is if someone tries to write a C (not C++) client
(meaning a linker) using MSVC.
>> #include <stddef.h>
>>
>> extern const char*
>> lto_get_error_message();
>
> I've tried not to create thread-unsafe designs in the rest of the
> bindings. I return a malloced error message by optional output
> parameters and provide a generic dispose function
> (LLVMDisposeMessage). Copying CFError's design might be smarter still.
There are other things not thread safe about the API. Adding a
string return would complicate the API. And it is possible to make
the API thread safe in the future by making lto_get_error_message()
return a per-thread string.
>
>> extern bool
>> lto_module_is_object_file_in_memory(const uint8_t* mem, size_t
>> length);
>>
>> extern bool
>> lto_module_is_object_file_in_memory_for_target(const uint8_t* mem,
>> size_t length,
>> const char*
>> target_triplet_prefix);
>>
>> extern lto_module_t
>> lto_module_create_from_memory(const uint8_t* mem, size_t length);
>
> Why not void*? Saves casting.
Fixed.
>> //
>> // generates code for all added modules into one object file
>> // On sucess returns a pointer to a generated mach-o buffer and
>> // length set to the buffer size. Client must free() the buffer
>> // when done.
>> // On failure, returns NULL (check lto_get_error_message() for
>> details)
>> //
>> extern const uint8_t*
>> lto_codegen_compile(lto_code_gen_t cg, size_t* length);
>
> The return value should be non-const. free takes a void*, not a
> const void*.
Fixed.
>> extern const char*
>> lto_module_get_target_triplet(lto_module_t mod);
>
> LLVM nomenclature is triple, not triplet.
Fixed.
>
>> extern uint32_t
>> lto_module_get_num_symbols(lto_module_t mod);
>>
>> extern const char*
>> lto_module_get_symbol_name(lto_module_t mod, uint32_t index);
>>
>> extern lto_symbol_attributes
>> lto_module_get_symbol_attribute(lto_module_t mod, uint32_t index);
>
> Why uint32_t instead of size_t?
I changed it to unsigned int. It is not pointer size dependent.
>
>> //
>> // frees all memory for a code generator
>> // upon return the lto_code_gen_t is no longer valid
>> //
>> extern void
>> lto_codegen_release(lto_code_gen_t);
>
> Existing bindings use the term dispose to avoid any possible retain/
> release confusion.
Changed both _release functions to _dispose.
-Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20080225/7fc6b7f5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lto.h
Type: application/octet-stream
Size: 6597 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20080225/7fc6b7f5/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20080225/7fc6b7f5/attachment-0001.html>