Re: Symbol availability in C, C++

[Albert Chin]

On Mon, Nov 28, 2005 at 01:04:10PM -0800, Paul Eggert wrote:
> Albert Chin <address@hidden> writes:
> 
> > I'm talking about _one_ project with two languages, C and C++. In
> > such a project, if human.h includes <stdint.h> because of
> > HAVE_STDINT_H, how should a C++ source file #include "human.h"
> > correctly when <stdint.h> isn't available to the C++ compiler?
> 
> Sorry, you'll have to bear with me because I'm not a C++ expert.
> 
> Traditionally, I assume it would be done by having the #include
> "human.h" inside an extern "C".  That is, inside extern "C", the usual
> C rules apply.

I'm not sure "the usual C rules apply" is correct. But, I'm nothing
close to a C++ expert. I think extern "C" simply means to use the "C"
naming convention for symbols (so you don't get C++ name mangling).

> What I hear you saying is that you have a C++/C compiler pair where
> extern "C" doesn't actually drop you into a mode that is compatible
> with C; it gives you a subset of the C features, one that lacks
> <stdint.h>.

Correct, in the above case. See my initial email for another example
with mbstate_t on HP-UX 11.23/IA.

> One way to fix this, I suppose, would be to have Autoconf test every C
> feature in both C mode and in C++-with-extern-"C" mode, and to
> consider the feature to be unsupported if either test fails.  This
> would require some autoconf hackery but shouldn't affect the source
> code.

Ick.

> Another way is to modify every header that is compiled by both C and
> C++ compilers, so that the header inspects two sets of feature macros,
> one for C and one for C++.  That is a more drastic and global change,
> one that I'd rather avoid.  As I understand it, that's the quick
> change that you put in.

I think this solution is more correct. Also, I think we can get away
with a minimal set of changes to work around the current list of
problems. That's probably good enough. We can always add to this as
problems arise.

> If <stdint.h> is the main problem here, another fix, and perhaps the
> best one, would be to supply a substitute <stdint.h> that is visible
> only to the C++ compiler.  That would require less autoconf hackery
> (and would also leave the source code alone).

We tried this with gl_STDINT_H. However, the custom stdint_.h defines
uintmax_t which conflicts with gl_AC_TYPE_UINTMAX_T.

-- 
albert chin (address@hidden)