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

[Alan Larson]

  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.