This is the mail archive of the 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: [PATCH] Don't rely on having LP64 in semaphores if 64b atomic ops are available.

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

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