This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Don't rely on having LP64 in semaphores if 64b atomic ops are available.
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: GLIBC Devel <libc-alpha at sourceware dot org>, Steve Ellcey <sellcey at mips dot com>, "Maciej W. Rozycki" <macro at linux-mips dot org>, "H.J. Lu" <hjl dot tools at gmail dot com>
- Date: Thu, 22 Jan 2015 19:08:12 +0000
- Subject: Re: [PATCH] Don't rely on having LP64 in semaphores if 64b atomic ops are available.
- Authentication-results: sourceware.org; auth=none
- References: <1421951065 dot 4572 dot 47 dot camel at triegel dot csb> <alpine dot DEB dot 2 dot 10 dot 1501221832100 dot 29901 at digraph dot polyomino dot org dot uk> <1421953170 dot 4572 dot 58 dot camel at triegel dot csb>
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