Bug#175025: dev_t problems with non-gcc compilers

[Ben Collins <bcollins@debian.org>]

> Well, I see it the other way :) Using the __GNUC__ macros from
> sysmacros.h makes it work. dev_t declarations seems to be:
> 
> // bits/types.h
> typedef __DEV_T_TYPE __dev_t;	/* Type of device numbers.  */
> 
> // bits/typesizes.h
> #define __DEV_T_TYPE		__UQUAD_TYPE
> 
> // bits/types.h
> /* Here we assume what is presently the case in all the GCC configurations
>    we support: long long is always 64 bits, ... */
> #define	__UQUAD_TYPE		unsigned long long int
> 
> ie. always long long. sysmacros.h is then just out of date with it's
> checks?

Unless something drastic changed between 2.3.1-5 and 2.3.1-8, your
headers are broken. I show this:

typedef __u_quad_t __dev_t;             /* Type of device numbers.  */

typedef struct
{
      __u_long __val[2];
} __u_quad_t;

The __u_quad_t is equal to "unsigned long long" when wordsize is 64 or
when __GNUC__ is defined.

If in fact your headers are pristine from 2.3.1-8, then it means the
glibc folks decided they weren't going to support compilers that didn't
support long long, and forgot the change sysmacros.h to reflect that.

> > Can
> > you get the preprocessed output before tcc gets it and see what dev_t is
> > typedef'd to?
> 
> tcc doesn't do preprocessing separately.

Then if tcc can't show you the preprocessing step, it's broken.

-- 
Debian     - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo       - http://www.deqo.com/