Re: Link failure with locale routines (when _MB_CAPABLE undefined)

[Eric Blake <eblake at redhat dot com>]

On 08/24/2016 08:42 AM, Corinna Vinschen wrote:
> On Aug 24 11:56, Richard Earnshaw (lists) wrote:
>> My builds last night all failed with:
>>
>> In file included from
>> /arm/scratch/rearnsha/gnusrc/gcc-cross/trunk/newlib/libc/stdlib/../locale/setlocale.h:38:0,
>>                  from
>> /arm/scratch/rearnsha/gnusrc/gcc-cross/trunk/newlib/libc/stdlib/local.h:8,
>>                  from
>> /arm/scratch/rearnsha/gnusrc/gcc-cross/trunk/newlib/libc/stdlib/efgcvt.c:140:
>> /arm/scratch/rearnsha/gnusrc/newlib/newlib/libc/include/locale.h:74:1:
>> error: unknown type name 'locale_t'; did you mean 'clockid_t'?
>>  locale_t _newlocale_r (struct _reent *, int, const char *, locale_t);
>>  ^~~~~~~~

> 
> Three ways to fix this:
> 
> - Revert the patch removing the POSIX-1.2008 feature tests.
>   This would be wrong since the _XXXlocale_r functions are *not*
>   POSIX, of course.

_XXXlocale_r functions are not POSIX, nor are they in the namespace
reserved for the implementation, so we still have to be careful about
avoiding pollution to the user's namespace.  As it is, I seem to recall
that single underscore followed by lower-case should only be used on
file-scope names, so exposing them in a header is already treading on
thin ice from a standards standpoint; we'd be safer with double
underscore or with single underscore and upper case.

> 
> - Remove the POSIX-1.2008 feature tests guarding the inclusion
>   of sys/_locale.h, providing the locale_t typedef.

The locale_t typedef, like ANY *_t name, is already reserved by POSIX,
and therefore can arguably be defined at any time regardless of feature
tests or particular header inclusions.  So blindly having locale_t
defined may be acceptable; although I would tend to favor a solution
that avoids the typedef except for cases where we have a specific header
exposing a specific function under current feature tests that actually
uses it.

> 
> - Use `struct __locale_t *' in those cases.

That seems like the safest - if you are using an internal function, then
using an internal type name is a sure way to avoid namespace pollution.

> 
> What would you prefer?

I'm leaning a bit towards the third option.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature