[LLVMdev] Integer questions

[Dan Gohman]

On Sep 8, 2008, at 7:18 PM, OvermindDL1 wrote:

> Do note though, that would cause an interface breaking change (just in
> the function signatures, but still).  An alternate would be to just
> pass in a struct that the user can subclass to perform their own error
> reporting, call a certain function in it or so before it finally bails
> out, it puts a level of indirection so if someone wants to recover
> they will have to use their own variables stored somewhere, so it is
> much more ugly and would not work well with C style bindings, whereas
> the interface breaking change would.  Or are there any other styles
> that are preferred?

I agree; having an abstract class interface for users to
subclass sounds like over-engineering here.

>
>
> On Mon, Sep 8, 2008 at 8:08 PM, OvermindDL1 <overminddl1 at gmail.com>  
> wrote:
>>> Patches to do the kind of checking you're asking about would be
>>> welcome :-). I don't think it makes sense to extend the
>>> Verifier itself here; it's supposed to accept any valid LLVM IR.
>>> I think a separate CodeGenVerifier might be a good approach
>>> though, or possibly extending codegen itself with the ability to
>>> interrupt itself and yield some kind of error status.
>>
>> And I presume you all are allergic to exceptions, since I have seen
>> none so far (probably due to help the C bindings and such), return
>> error codes all over the place then?  If I do any extension on this
>> (short on time, so good chance I cannot, but if I do) the usual
>> non-exception style I use is the return value is a status code, the
>> last argument passed in is an optional std::string* (the return code
>> gives the basic error reason, the string gives details), anything  
>> that
>> actually needs to be returned are the first arguments as
>> references/pointers, would that work?

I don't know what the best approach is. It would need to be something
that doesn't interfere with users who don't need it, and presumably it
would need to be good enough to meet your needs.

Dan