libc-config and system-reserved symbols

[Bruno Haible <bruno@clisp.org>]

Hi Paul,

I wrote:
> The cause is that Android has its own framework for defining fortified
> variants of the string operations, and like glibc it uses macros named
> '__bos' and '__bos0'. But these macros have different definitions in
> Android than in glibc.

This situation can happen with any symbols that are prefixed with __
and are therefore system-reserved.

As far as I understand, the general approach of this cdefs.h is that
it defines __ prefixed macros for glibc, and there are two categories:
  (A) Those that become active in gnulib as well.
  (B) Those that are not active in gnulib.

For porting more code from glibc to gnulib, and for avoiding surprises
when pulling new versions of existing modules from glibc to gnulib,
it is useful when the set (A) is large.

On the other hand, to avoid conflicts with existing platforms, the
set (A) should be small.

Today, I moved the Fortify-related symbols from (A) to (B).

But I claim that the set (A) is still too large.

1) Look at the defined symbols: Some, such as __P, __PMT, etc.
   are not used by the code that Gnulib borrows from glibc.
   Each such symbol could have a meaning different from the glibc one
   on some platform.

2) Speaking specifically about Android, I compared the definitions.
After eliminating equivalentr definitions, the remainder is:

Gnulib <cdefs.h>:
#  define __inline      inline
#  define __inline              /* No inline functions.  */
# define __THROW
# define __THROWNL
# define __NTH(fct)     fct
#define __CONCAT(x,y)   x ## y
#define __STRING(x)     #x
#define __bos(ptr) __builtin_object_size (ptr, __USE_FORTIFY_LEVEL > 1)
#define __bos0(ptr) __builtin_object_size (ptr, 0)
# define __warnattr(msg) __attribute__((__warning__ (msg)))
# define __warnattr(msg)
# define __attribute_warn_unused_result__ \
#  define __wur __attribute_warn_unused_result__
# define __attribute_warn_unused_result__ /* empty */
# define __always_inline __inline __attribute__ ((__always_inline__))
# define __always_inline __inline
#  define __extern_inline extern __inline __attribute__ ((__gnu_inline__))
#  define __extern_always_inline \
#  define __extern_inline extern __inline
#  define __extern_always_inline extern __always_inline

Android <sys/cdefs.h>:
#define __CONCAT1(x,y)  x ## y
#define __CONCAT(x,y)   __CONCAT1(x,y)
#define ___CONCAT(x,y)  __CONCAT(x,y)
#define __inline        inline          /* convert to C++ keyword */
#define __always_inline __attribute__((__always_inline__))
#define __warnattr(msg) __attribute__((deprecated(msg)))
#define __bos(s) __bosn((s), __bos_level)
#  define __bos0(s) __bosn((s), 0)

Notice in particular:
  - the different definitions of __CONCAT
  - the different definitions of __inline
  - the different definitions of __always_inline
  - the different definitions of __warnattr

I would not be surprised if these macros cause trouble, either on Android
or on other platforms, in the future.

Bruno