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

[Alan Larson]

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

From: Alan Larson <larson at w6yx.stanford.edu>
To: brde at optusnet.com.au, larson at w6yx.stanford.edu
Cc: 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: Thu, 30 Jun 2011 17:14:04 -0700 (PDT)

   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 )
 >
 > Unfortunately, breaking is the correct behaviour since the ABI depends on
 > the struct layout, so only compilers that support packing and alignment
 > can work.  Structs should be layed out more carefully so that packing and
 > alignment directives are never needed, but this is sometimes impossible.
 
 
   Fortunately, both PCC and TCC do support packing and alignment.
 
 
 > >> How-To-Repeat:
 > >
 > >  Attempt to compile something that has an #include <signal.h> with TCC (or presumably, PCC).
 > >
 > >  Inspection of the code indicates that the same problem is true for __packed  .
 > >
 > >  Other values are also redefined in those same conditionals, and they probably have
 > > the same problems.
 >
 > The problem outside the kernel doesn't seem to affect much more than
 > <signal.h>, though relatively recently it has spread to some networking
 > headers, especially ipv6 ones.
 
 
 > >  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.
 
 
 
 > 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
 
 
   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.
 
 
 	Alan
 
 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.