Re: sys-socket.in.h/alignof.h usage problem with C++

[Eric Blake]

On 08/22/2010 08:54 AM, Gary V. Vaughan wrote:
> While trying to compile a C++ package, and using the gnulib socket modules to 
> paper over the differences between various vendor implementations, I tripped 
> over the following error on Solaris 2.6 and 7:
>
> "lib/alignof.h", line 28: Error: Template declarations cannot have extern "C" 
> linkage.
> 1 Error(s) detected.
>
> Triggered by the following code in alignof.h:
>
> /* Determine the alignment of a structure slot (field) of a given type,
>     at compile time.  Note that the result depends on the ABI.
>     Note: The result cannot be used as a value for an 'enum' constant,
>     due to bugs in HP-UX 10.20 cc and AIX 3.2.5 xlc.  */
> #if defined __cplusplus
>    template<class type>  struct alignof_helper { char __slot1; type __slot2; };
> ...
>
> The problem is that the package C++ headers wrap inclusions of C headers in `extern 
> "C"', which seems like a reasonable thing to do.

No, it does not sound reasonable to me.  Well-written system headers 
should already be accommodating to C++ without needing extra help from 
clients.

> I'm curious who is wrong here: Is it wrong for gnulib's alignof.h to use C++ conditionally and assume that it 
> is not included from inside an `extern "C"' in an outer file?  Is it wrong for the package to 
> mistrust the system C headers so much that they are only included to a C++ file inside an `extern 
> "C"' declaration?  Or is it wrong for the C++ compiler to complain about use of templates inside 
> `extern "C"'?

The compiler is right to complain about templates inside of extern "C".

Since I'm claiming that any system header is broken if it requires an 
external 'extern "C"' block to behave correctly in C++, and since gnulib 
is designed to provide replacement headers around broken headers, it 
follows that gnulib should be able to fix the brokenness of any such 
system header in a manner transparent to your program (but we can only 
test for and fix such brokenness when it is reported).

> I have a workaround already (moving `#include<sys/socket.h>' outside the `extern 
> "C"'), but I'm curious about the real culprit, and maybe the gnulib generated headers 
> want to work properly when used like this?

I would say that your workaround is the correct approach; none of the 
headers provided by gnulib should ever appear inside your program's 
extern "C" blocks.  But we should probably document that intent better.

--
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org