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

[Joseph Myers]

On Thu, 22 Jan 2015, Torvald Riegel wrote:

> > 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;
> 
> Looking at other glibc code, I had assumed that using uint32_t and
> uint64_t wouldn't be current practice.  Are you saying that future
> clean-up towards that (e.g., using uint64_t instead of "unsigned long
> long" as in this patch) would be welcome?

I'd welcome it, if 64-bit types are logically what the code wants; libm 
code at least makes plenty of use of such names.  (That doesn't 
necessarily mean we want UINT64_C etc. used for constants; we'd need to 
think about whether we want to be more verbose like that.)

For code maintained in glibc as opposed to imported from elsewhere, I 
think moving from u_intN_t type names to the ISO C uintN_t type names 
(with inclusion of <stdint.h>) is also a sensible cleanup - though in 
installed headers you'd need to watch out for other symbols from 
<stdint.h> that might not be appropriate for some other header to define.

-- 
Joseph S. Myers
joseph@codesourcery.com