Re: compiler standards (and/or min gcc version) supported withinstalled headers ?

[Roland McGrath <roland at hack dot frob dot com>]

> My argument for requiring long long (at least on 32-bit platforms, but I 
> really doubt there are compilers for 64-bit platforms supported by glibc 
> that don't have long long), in addition to C90/C++98, is that it's not 
> simply functions with long long directly in their interfaces; bits/types.h 
> defines a load of typedefs, some of which are 64-bit, and those typedefs 
> in turn are used in other places in various interfaces and structures, for 
> example.  And the versions of __quad_t / __u_quad_t that are defined as 
> structures in the absence of __GLIBC_HAVE_LONG_LONG may well not be ABI 
> compatible with long long (in terms of alignment or function call 
> interfaces, or of course C++ name mangling), and of course don't actually 
> meet any requirements on various types to be arithmetic types.

I agree that the ABI issue is of concern.  I think it would be fine not to
define __quad_t at all, nor define nor declare anything that flows from it,
if __GLIBC_HAVE_LONG_LONG is not set.  Then it would be impossible to
compile something that would not be ABI-compatible.

I suspect that is doable in the sense that all the types that use those
things and the interfaces that use them are explicit *ll or *64 interfaces.
But it would be a whole lot of conditionalization and extremely tedious to
track it all down, putting it well within the "extreme maintenance burden"
territory for little to no practical benefit to any user.

> I think "long long" is widespread enough that it's more practical to
> treat it as something required from any compiler used to build programs
> with glibc, rather than to attempt to provide compatibility for compilers
> without it.

Yeah.  OK, I relent.  C89 plus 'long long' is an acceptable baseline.
Note that this doesn't remove the need to use __extension__ everywhere
on 'long long' uses.


Thanks,
Roland