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

Eli Friedman eli.friedman at gmail.com
Mon Feb 6 14:47:56 PST 2012


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.

>> "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.

>> 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.

> Btw, this is in response to Bug 6143 (http://llvm.org/bugs/show_bug.cgi?id=6143)

Thanks for the reference.

-Eli




More information about the cfe-commits mailing list