[cfe-commits] [PATCH] Warn on non-compatible returns from extern "C" functions

[Aaron Ballman]

On Mon, Feb 6, 2012 at 4:47 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
> On Mon, Feb 6, 2012 at 2:40 PM, Aaron Ballman <aaron at aaronballman.com> wrote:
>> On Mon, Feb 6, 2012 at 4:33 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
>>> On Sun, Feb 5, 2012 at 9:31 AM, Aaron Ballman <aaron at aaronballman.com> wrote:
>>>> MSVC will warn the user when a declared return type of an extern "C"
>>>> function is not C-compatible
>>>> (http://msdn.microsoft.com/en-us/library/1e02627y(v=vs.100).aspx).
>>>> This patch adds the same style of warning to clang, under the
>>>> -Wreturn-type group, with test cases.
>>>>
>>>> Is there a better way for me to check whether a type is "C compatible?"
>>>
>>> CXXRecordDecl::isCLike was added recently... not sure if it's what you want.
>>
>> Thanks, I'll check it out.
>
> Thinking about it a bit more, isPOD is probably closer to what you
> want... since you're actually worried about whether we guarantee C
> compatibility, not whether the struct could be copy-pasted into a C
> program.

I looked at isCLike and it looks like it could be suitable as well.
It is checking whether it's a POD, but also ensuring that it's not a
class, template, and it has only C members.  However, I'd still need
to make sure it's not void or one of the fundamental C types (int,
char, etc).

>>> "UDT" is not a term we use anywhere in clang; please don't use it here.
>>
>> Suggestions on alternative wording?
>
> You could just expand out its definition.  MSVC's warning appears to
> be much more aggressive than what you are implementing here.

Fair enough, thanks!

>>> That said, I really don't understand the point of this warning.
>>
>> class A {
>> public:
>>  A(const A&);
>> };
>>
>> extern "C" A NotGoingToWork( void );
>>
>> If the intention is to flag the function for export via C linkage, how
>> would that work when the return value is a class type?  It seems to me
>> that this is a sensible place for a warning since the resulting code
>> doesn't match the user's expectations.
>
> Sure, but how would someone actually end up in this situation?  Most
> cases where extern "C" is used, the relevant header is shared between
> C and C++ code.  And even if it isn't, the issue would become
> immediately obvious when you tried to define "A" in the C file.

Another good situation would be for non-C languages that still use
interop (.NET languages, for instance) where there is no header
involved.

~Aaron