This is the mail archive of the mailing list for the newlib project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Aug 24 09:02, Eric Blake wrote:
> 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.

All other _foo_r functions have a single underscore for ages.
I'm cetainly not going to introduce a new naming convention for
these functions.

Alternatively we just drop them entirely.  I introduced them
for symmetry since there's a _setlocale_r as well.

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

Ok, thanks for your input.

Anybody else?


Corinna Vinschen
Cygwin Maintainer
Red Hat

Attachment: signature.asc
Description: PGP signature

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]