[LLVMdev] PATCH: AddressSanitizer: Fix errors about mis-matched exception specifiers for intercepted libc functions on Linux

[Chandler Carruth]

I really don't see why this is the correct fix.

1) I like including the system's headers. It ensures that the interceptor
DTRT.
2) It's hardly the only system header you pull in here
3) I think we should probably match what glibc does when declaring these
routines. any reason to avoid this?

On Mon, Jun 25, 2012 at 3:00 AM, Kostya Serebryany <kcc at google.com> wrote:

> done: r159132.
>
>
> On Mon, Jun 25, 2012 at 1:47 PM, Kostya Serebryany <kcc at google.com> wrote:
>
>> .. And the right fix would be to completely get rid of "#include
>> <malloc.h>" in this file.
>> I'll do that change.
>>
>> --kcc
>>
>>
>> On Mon, Jun 25, 2012 at 1:42 PM, Alexander Potapenko <glider at google.com>wrote:
>>
>>> On Mon, Jun 25, 2012 at 1:10 PM, Chandler Carruth <chandlerc at google.com>
>>> wrote:
>>> > Hello,
>>> >
>>> > On modern Linux installs, glibc has a very annoying practice: it adds
>>> an
>>> > empty exception specifier to lots of libc functions as an
>>> optimization. It
>>> > only does this if the compiler is modern and GCC-like, and we are
>>> compiling
>>> > in C++ mode.
>>> >
>>> > This, however, causes GCC to complain about signature mismatches
>>> between the
>>> > glibc functions declared in malloc.h and those defined as an alias in
>>> the
>>> > interceptors library:
>>> >
>>> > ..../asan_malloc_linux.cc:57:1: error: declaration of 'void
>>> free(void*)' has
>>> > a different exception specifier
>>> > /usr/include/malloc.h:66:13: error: from previous declaration 'void
>>> > free(void*) throw ()'
>>> Looking at /usr/include/malloc.h I don't see any instances of throw()
>>> (Goobuntu Lucid)
>>> Shouldn't we have the same set of standard headers?
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120625/a130a1c6/attachment.html>