Re: Fix for AC_HEADER_MAJOR for glibc + non-gcc

[Pavel Roskin]

Hi, Paul!

> I'm a bit dubious about that patch.  Older hosts lack dev_t, so if we
> require dev_t in the test program, those older hosts will wrongly fail
> the test.  Perhaps if you checked for dev_t first....

I thought about it, but I thought that dev_t always comes with major() and
minor().  Thanks for correcting me.

Actually, replacing dev_t would be non-trivial if we allow it to be an
array.  On the other hand, AC_CHECK_SIZEOF seems to work with arrays, so
the existence of the type can be checked.

> ... but that raises my next objection, namely that implementations
> where dev_t is an array type do not conform to POSIX and are a porting
> hassle that these macros do not really address.

I agree.  If you the code compares variables of type dev_t (i.e. to make
sute that it's the same file), they all should be changed to something
like "memcmp (dev1, dev2, sizeof(dev_t))"

If some standard functions, such as stat(), require "long long" to be 
supported, it should be reasonable to assume that is supported. 

> I used to worry about hosts with brain damaged system types like that.
> However, I stopped worrying about them a few years ago, and have never
> regretted it.  It's such a hassle dealing with systems where you can't
> compare dev_t values with == (or even with memcmp, for that matter).

It's very late as I'm writing it, so let me ask a dumb question - what's
wrong with memcmp?  dev_t is not a pointer - it's the array itself.  From
glibc-2.2.4 headers (if not GCC):

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

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

I think that supporting more than on compiler on GNU/Linux is very 
important - it means more choice and new (potentially useful) warnings 
about unportable or nonstandard code.

-- 
Regards,
Pavel Roskin