This is the mail archive of the newlib@sourceware.org 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] |
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? Thanks, Corinna -- 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] |