bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-gnulib] Re: include-once-only macros


From: Bruno Haible
Subject: [Bug-gnulib] Re: include-once-only macros
Date: Tue, 28 Sep 2004 16:54:35 +0200
User-agent: KMail/1.5

Simon Josefsson wrote:
> I thought that POSIX (or C99?) implied user code shouldn't use CPP
> symbols that began with '_'?  The Libtool manual says:
>
>    Note that the `#ifndef FOO_H' prevents the body of `foo.h' from
>    being read more than once in a given compilation.
> ...
>    (1) We used to recommend `__P', `__BEGIN_DECLS' and `__END_DECLS'.
>    This was bad advice since symbols (even preprocessor macro names) that
>    begin with an underscore are reserved for the use of the compiler.

Yes, that's the theory.

The practice is that one should avoid identifiers starting with '__',
since they are very likely to lead to collisions. Symbols that start
with '_' - in my experience - give less collisions than those without.

> I'm not sure I follow.  Does, for example, SVR4/Solaris then define
> DS_H?  I guess symbols like *_H would occur less natural.

Symbols ending in *_H are less frequent than the others (DS, EAX, ...) indeed.
But nevertheless. Here are those *_H macros on a Linux system that don't
designate a header file:

   #define COFF_SHORT_H(ps) ...
   #define COFF_LONG_H(ps) ...
   #define FDC1772CMDADD_H (0x08)
   #define BPF_H 0x08
   #define KEY_H 35
   #define ETIP_NEEDS_MATH_H 0
   #define XK_H 0x048

None of them has an underscore. I bet the situation on other systems is
the same.

Bruno





reply via email to

[Prev in Thread] Current Thread [Next in Thread]