[llvm-commits] [PATCH] Suppress "user-defined return type in extern C" warning under Clang

[Matt Johnson]

On 02/14/2012 02:56 PM, Aaron Ballman wrote:
> On Tue, Feb 14, 2012 at 2:50 PM, Matt Johnson<johnso87 at illinois.edu>  wrote:
>> On 02/14/2012 02:42 PM, Aaron Ballman wrote:
>>> On Tue, Feb 14, 2012 at 2:28 PM, David Blaikie<dblaikie at gmail.com>    wrote:
>>>> [+aaron who added this warning&    was already looking into the fix for
>>>> LLVM]
>>>>
>>>>
>>>> Perhaps you've got the right fix - but at least Aaron won't keep
>>>> working on it redundantly. It looks reasonable to me.
>>> The patch looks like it will work the same for clang as it does for
>>> MSVC, which is good.  But I'm a bit concerned as to why we have an
>>> extern "C" function that returns a type that can't be represented in
>>> C.  Is that the problem we should be solving instead?
>> My understanding is that we're declaring these functions as 'extern "C"' not
>> to actually call them from C code, but just to avoid mangling.  The VS2010
>> docs (http://msdn.microsoft.com/en-us/library/1e02627y.aspx) state that if
>> the definition and all calls are *actually* C++ code, doing this is legal.
>>   I'm far from an authority on the matter, but it sounds reasonable.
> That certainly is true, and is reasonable.  :-)  I'm just trying to
> figure out the "why" part of it.  Why do we not want mangled names in
> this situation?  If it makes sense, which I'm betting it does, then
> your fix is great.  If we want non-mangled names for some sort of
> interoperability, then I think we may want to do something other than
> suppress the warning.
I'm guessing it's just to make it reasonable to export some common 
functions to interpreted applications without depending on libffi or 
requiring DynamicLibrary::SearchForAddressOfSymbol() to implement 
mangling or depend on libsupc++, libc++abi, or similar (for no obvious 
benefit other than whatever intrinsic ugliness of 'extern "C"'.  lle_X 
seems like a reasonable prefix which doesn't conflict with _Z or other 
mangling prefixes I'm aware of.
>
> ~Aaron