Eric Blake <ebl...@redhat.com> writes:
> On 10/19/2011 05:06 AM, Simon Josefsson wrote:
>> This is not related to gnulib strictly, but I'd like to consult the
>> wisdom on this list. I'm considering changing the argument to some
>> functions in GNU Libidn from 'enum' to 'int' to silence C++ warnings
>> (see [1] for discussion). The change I'm considering is from:
>>
>> typedef enum
>> {
>> ...
>> } Idna_rc;
>> ...
>> extern IDNAPI const char *idna_strerror (Idna_rc rc);
>>
>> into
>>
>> extern IDNAPI const char *idna_strerror (int rc);
>>
>> Some things that I wonder:
>>
>> 1) Is there any platform where this has any implications for the ABI?
>
> Name mangling is part of the ABI, and C++ requires enum names to be
> part of the mangling. If your functions were labeled extern "C", then
> there is (probably) no ABI difference between enum and int, although I
> think the language standards allow the compiler to use a narrower type
> than int if the enum can be proved to fit in the narrower type.
I'm hoping there are no such compiler, then. It seems fragile for a
compiler to do that, as it would need to make sure that it always picks
the same size for the enum when building libraries and when building
applications that use the library.
> But for extern C++ functions, changing the argument type means that
> you are linking against a different symbol, so applications compiled
> against the old library will not find the entry point in the new
> library.
>
> In your code, does IDNAPI expand to "C"? If so, then mangling is not
> an issue. If not, then use function overloading to keep the old
> signature while also providing the new signature.
All function prototypes are within extern "C" blocks, so I believe name
mangling is not an issue. Libidn is a C library, although it should be
usable from C++ too.
Thanks for response,
Simon
