Re: [PATCH] Don't rely on having LP64 in semaphores if 64b atomic ops are available.

[Joseph Myers <joseph at codesourcery dot com>]

On Thu, 22 Jan 2015, Torvald Riegel wrote:

> Also, do we already have any information on which data models we
> support?  I reckon LP64 and ILP32?, or others as well?  I'd like to add
> a comment to atomic.h, and if we have such information already, I'd just
> point to it.

I believe we can assume: 8-bit char (may be signed or unsigned), 16-bit 
short, 32-bit int, long either 32-bit or 64-bit and the same width as 
pointers, long long 64-bit.  But registers (and so syscall arguments) may 
be 64-bit even with 32-bit long; architectures may vary about the 
significance of high bits of function arguments and return values.

I could imagine there being a future glibc port where intmax_t is 128-bit 
(with __int128 being a proper integer type rather than an extended type 
that looks quite like an integer type but doesn't meet all the 
requirements), although that's certainly outside the set of ABIs supported 
by glibc at present (which expect intmax_t to be 64-bit like long long).

If code needs types of a given width (e.g. manipulating bits of a 
floating-point number), it is of course good practice for it to use 
<stdint.h> types rather than embedding assumptions that e.g. int means 
32-bit; similarly, use of intptr_t / uintptr_t when casting between 
pointers and integers is to be preferred to use of long; use size_t for 
in-memory sizes (although in fact all ports have size_t the same width as 
unsigned long); and so on.

The GNU Coding Standards specifically say no support is needed for size_t 
wider than long - that applies to all GNU software, not just glibc (which 
is portable to a more restricted range of systems).

-- 
Joseph S. Myers
joseph@codesourcery.com