On Oct 13, 2008, at 3:16 PM, Chris Lattner wrote:
>
> On Oct 13, 2008, at 1:10 PM, Robert Zeh wrote:
>
>>
>> On Oct 13, 2008, at 1:07 PM, Chris Lattner wrote:
>>>
>>> Exceptions have a high cost in terms of code size, binary size, and
>>> even a bit of execution time.
I agree. I think the client should be allowed to choose whether to
compile these in or not. At the LLVM library level, this may have to
be compile-time selected (which could be a bit ugly but should not be
too bad) to avoid the code size problem.
>>> Also, they don't magically make the
>>> code safe from any error: code has to be designed specifically to
>>> use
>>> RAII and other techniques to handle exceptions properly.
I understand that -- you're not making the client's life easy,
you're
just making it possible.
>>> Reading a
>>> C+
>>> + trade magazines/books about EH topics will give you an idea of
the
>>> complexity involved in doing it right. Further, as I mentioned up-
>>> thread, turning aborts into exception throws won't save you
from
>>> null
>>> pointer or garbage pointer dereferences.
>>
>>
>> You can catch the null pointer and garbage pointer dereferences
>> with a
>> signal handler (in Linux land, at least), and then invoke your direct
>> reporting mechanism with that. Is the concern that some of the other
>> LLVM clients don't have signal handling?
>
> Garbage/dangling pointers can corrupt memory, they don't always trap.
> C just isn't a safe programming language (though there are many
> interesting research projects that can help).
Yes, but that's a case that LLVM would not do any error reporting
anyway. In any case, where it would otherwise report an error, it
seems to me you could give the client the *option* to handle the
signal and throw an exception, if needed, and then field the exception.
>
>
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev