[cfe-dev] Handling of empty structs in C

David Blaikie dblaikie at gmail.com
Tue Nov 5 11:34:00 PST 2013


On Tue, Nov 5, 2013 at 11:19 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk
> wrote:

> On 5 Nov 2013, at 18:19, Reid Kleckner <rnk at google.com> wrote:
>
> > IMO extern "C" is a clear indication that the user wants to interoperate
> between C and C++.  clang should have this warning on by default in extern
> "C" contexts.
>
> The problem is that the compiler only sees the extern "C" when compiling
> in C++ mode, but the author of the header most likely compiles
> predominantly in C mode.
>

Sure, but it'll help the end user to see a warning as soon as they compile
in C++ mode, this seems like a big step up from runtime problems. I'm not
sure how much the added complexity of a pragma, etc, would add over this.


>
> It would be nice to have an annotation that could be added to a header
> that would let the compiler (or some tool) automatically check that it
> would work if compiled in either C or C++ mode.
>
> To check properly, you'd need to parse it as both C and C++ and do the
> full range of checks, ideally also checking that symbols have the same
> linkage in both versions.
>
> For a simple example of why this is difficult, in FreeBSD libc (and many
> other libc implementations) we have __BEGIN_DECLS and __END_DECLS macros.
>  These expand to extern "C" { and } respectively in C++ mode, or to nothing
> in C mode.  Just looking for extern "C", even inside an #ifdef, won't help
> you.
>
> I'd like to see such a tool, and ideally one that would let you specify
> what language dialects you expect a header to be valid for.  For example:
>
> #pragma clang valid_languages c99, c89, gnu99, gnu++99
>
> Although ideally something other than a pragma, so that we could have a
> __VALID_C and __VALID_CXX macros that would expand to something different
> depending on the compiler and the language dialects that we care about.
>
> The tool would then check trivial compatibility (does this file parse as
> valid code in all of these dialects),


Might be a nice tool, sure - but it's still going to be an extra tool, I'd
imagine, not just a flag passed to the compiler - at which point it's
probably just as easy for someone to setup their build system with a few
different configurations they want to ensure correctness for.


> but also less trivial properties, including:
>
> - Are all C structs declared in it POD types in C++?
> - Are all C functions extern "C" linkage in C++?
> - ...?
>
> David
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131105/1e2e38a7/attachment.html>


More information about the cfe-dev mailing list