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

[Gary V. Vaughan]

Hi Eric,

Thanks for the feedback.

On 23 Aug 2010, at 21:47, Eric Blake wrote:
> 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.

Well, we are talking about old Solaris here: well-written solaris system 
headers is an oxymoron! I imagine the upstream developers of this package 
(epics-base-3.14.11) put the extern "C" in to their solaris-specific headers to 
fix a problem they encountered at some point.  The libraries it builds are 
assembled from a selection of C and C++ objects, which is the most likely 
scenario I can imagine to trigger a bug that might have needed the extern "C" 
blocks to fix...

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

Although only Solaris 2.6 and 7 (at the newest available vendor compiler 
patch-level AFAICT) complain... Solaris 8, 9 and 10 work, although that may be 
because gnulib sys/socket.h doesn't need alignof.h with the newer compilers, 
and thus doesn't trigger the bug.  I can investigate anything that is useful to 
helping gnulib cope if you'd like.

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

If it is a lot of work to do that (and actually, I can't think of any straight 
forward way for
alignof.h to know whether it is already inside an `extern "C"' block), please 
don't do it on my account.  I'm quite happy with the patching the package 
headers to avoid the issue.

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

IMHO that's all that's necessary in this case.

Cheers,
-- 
Gary V. Vaughan (address@hidden)

PGP.sig
Description: This is a digitally signed message part