This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Tue, 8 Jan 2013, Roland McGrath wrote:

> Similarly, if a compiler doesn't support 'long long' then it's fine if
> we just don't declare strtoll in stdlib.h, for example.

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 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.

(GCC likewise generally expects a 64-bit integer type to be available from 
the host compiler used for bootstrapping.)

-- 
Joseph S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]