misc/158418: /usr/include librarys broken by unnecessary extra macro indirection.

[Bruce Evans]

The following reply was made to PR kern/158418; it has been noted by GNATS.

From: Bruce Evans <brde at optusnet.com.au>
To: Alan Larson <larson at w6yx.stanford.edu>
Cc: brde at optusnet.com.au, freebsd-bugs at freebsd.org,
        FreeBSD-gnats-submit at freebsd.org
Subject: Re: misc/158418: /usr/include librarys broken by unnecessary extra
 macro indirection.
Date: Fri, 1 Jul 2011 17:01:19 +1000 (EST)

 On Thu, 30 Jun 2011, Alan Larson wrote:
 
 >  Thanks for your reply.  Perhaps I need to clarify a few details.
 >
 >> On Tue, 28 Jun 2011, Alan Larson wrote:
 >>
 >>>> Description:
 >>>
 >>>  The macro  __aligned(x)  is used several places in files in /usr/include, but is only
 >>> defined if using a sufficiently new version of GCC, or an Intel compiler.
 >>> The definitions are inside an  #if __GNUC_PREREQ__(2, 7)  and  #if defined(__INTEL_COMPILER)
 >>>
 >>>  This breaks things when compiled with PCC or TCC.  ( http://pcc.ludd.ltu.se/jira/browse/PCC-18 )
 > ...
 >>>  Two likely fixes come to mind:
 >>>
 >>>    1.  Don't use these macro shortcuts, use the __attribute__ form directly.
 >>>        Many of the files in /usr/include do this, so fixing the remaining ones
 >>>        would simplify things.  It should only take a few minutes to fix them.
 >>>        There are still lots of places using the __attribute__ form, so this
 >>>        is a proven safe and reasonable solution.
 >>
 >> That would enlarge the bug.  Doing it for an old version of tcc -Ysystem
 >> gives:
 >>
 >> % "/usr/include/machine/signal.h", line 122: Error:
 >> %   [Syntax]: Parse error before '__attribute__'.
 >> %   [Syntax]: Can't recover from this error.
 >>
 >> since old versions of tcc don't support __attribute__ any more than they
 >> support the newer types of attributes like the one for alignment.
 >
 >  This is actually not a problem, or at least not *the* problem.  tcc supports
 > these __attribute__ options, and in the many cases where they are used without
 > the conditional definitions, is happy with them.
 >
 >  I checked with the November 2004 version 0.9.22 of tcc.
 
 Perhaps a different tcc.  I checked with an old version of TenDRA which is
 actually less old than the above:
 (tcc: Version: 4.0, Machine: freebsd-*-80x86, Release: TenDRA-5.0.0-dev)
 but which is tool old to support much more than C90 (and 1990's (?) C++).
 
 >> The macros are not just shortcuts, but exist primarily to avoid hard-coding
 >> gccisms like __attribute__ in lots of places.
 >
 >  Well, it seemed easier than including the macos for every possible compiler, but
 > if you prefer, please add this to sys/cdefs.h
 >
 > #ifdef __TINYC__
 > #define	__dead2		__attribute__((__noreturn__))
 > #define	__pure2		__attribute__((__const__))
 > #define	__unused	__attribute__((__unused__))
 > #define	__used		__attribute__((__used__))
 > #define	__packed	__attribute__((__packed__))
 > #define	__aligned(x)	__attribute__((__aligned__(x)))
 > #define	__section(x)	__attribute__((__section__(x)))
 > #endif
 
 You need to get this added undef suitable ifdefs in sys/cdefs.h.  __TINYC__
 might be OK, but does it need a version ifdef?  Perhaps it should be
 organized differently, but that should be left to the committer.
 
 >  Actually, it may make more sense to just define them unless you know the compiler cannot
 > handle them, and it would probably be a shorter .h file, too.
 
 That would be fail-unsafe.
 
 > p.s. is there are reason that the intel compiler version says #define<space>__blah
 > while the GCC one says #define<tab>_blah ?  As you can see, I used the tab version
 > because I know that worked with TINYC.
 
 It is because the committer of the Intel compiler version didn't follow
 the style of the rest of the file :-(.  The organization of the intel
 compiler ifdefs isn't very good either.  The __INTEL_COMPILER section
 for most attributes just duplicates the __GNUC_PREREQ(2, 7) for these
 attributes, except for adding the style bug.  It could have just
 expanded the ifdef's conditional.  The above __TINYC__ ifdef could do
 the same -- just add " || __TINYC__" to the ifdef conditional.  But
 this only works well if there is a large group of macros that are all
 supported by most compilers of interest.  New and old features like
 attributes will in general require different version-dependent ifdefs,
 depending on when the compilers introduced them.  This only matters
 much at the time when the features are introduced.  I think half of
 the attributes under the __GNUC_PREREQ(2, 7) attributes ifdef weren't
 actually available until gcc-3 (especially __used), but the bugs weren't
 noticed because the ifdef wasn't added until long after the features
 became standard, and no one cares now since it is hard to even find
 any gcc-2.7's to test what it didn't have.  Ifdefs for older features
 are more accurate but could be deleted without much loss now for the
 same reason.
 
 The second round of Intel compiler ifdefs also brought another style of
 ifdefs in which every single feature has its own feature test macro.
 E.g., there is __GNUCLIKE___TYPEOF for gcc __typeof(), and
 __CC_SUPPORTS_INLINE for Standard C99 inline.  With macros like these,
 users of foocc could possibly enable the definitions using the features
 by #defining the macros in their source code if the system doesn't.
 But this style of ifdefs is not used for most attributes, and is only
 honored in a few system header files (mainly i386 ones, since
 __INTEL_COMPILER only works for i386), and it seems to give an even
 larger ifdef tangle when used.
 
 Note than the Intel compiler support is rarely used and incompletely
 maintained.  Replacing it by Other compiler support for a compiler
 that is used would be could.  At least if it doesn't enlarge the
 ifdef tangle.  Now the alternative compiler is usually clang, but
 clang's compatibility with gcc is too good for it to need many ifdefs.
 
 Bruce