On Tue, May 1, 2012 at 10:29 AM, Simon Marlow <[email protected]> wrote: > On 01/05/2012 16:05, Gabriel Dos Reis wrote: >> >> On Tue, May 1, 2012 at 5:11 AM, Simon Marlow<[email protected]> wrote: >>> >>> On 01/05/2012 10:58, Gabriel Dos Reis wrote: >>>> >>>> >>>> On Tue, May 1, 2012 at 3:24 AM, Simon Marlow<[email protected]> >>>> wrote: >>>>> >>>>> >>>>> On 27/04/2012 17:46, Ian Lynagh wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Apr 27, 2012 at 04:58:14PM +0100, Simon Marlow wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hmm, I indended lnat to be shorthand for "unsigned long". I'd much >>>>>>> rather we used size_t when we mean that, and keep lnat as meaning >>>>>>> "unsigned long". >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I'm certainly happy with using size_t instead of lnat. >>>>>> >>>>>> When should lnat be used, though? When would you want a 32-bit value >>>>>> on >>>>>> Windows/x86_64, but a 64-bit value on Linux/x86_64? >>>>> >>>>> >>>>> >>>>> >>>>> That's a good point. I'd be ok with lnat being 64 bits on Windows/x64. >>>> >>>> >>>> >>>> 'long', 'int', size_t, carry uncertainty about their precisions. Any >>>> reason not to use >>>> the sized integer types (where available, but these days they are on all >>>> platforms that GHC cares about.) >>>> >>>> In general, I would use 'int', 'long', etc. only when mandated by the >>>> host system APIs. >>>> Everywhere else I would be explicit about the integer type precision >>>> -- unless it really does >>>> not matter. >>> >>> >>> >>> Sometimes we want to use either 32 bits or 64 bits depending on the >>> machine >>> word size, e.g. when the value represents the size of a memory object. >>> Perhaps in those cases we should be using size_t (I'm a bit hazy on what >>> the exact meaning of size_t is though, so I generally prefer to define >>> these >>> things myself). >> >> >> I guess a question is what it meant by "word"? The width of >> the CPU general purpose register? The width of a data pointer? >> Even in 64-bit mode, some ABIs use ILP32 (e.g. the case of the x32 ABI >> or the MIPS N32 ABI). I know of only one case of LLP64 ABI >> where size_t is still 32-bit, but I am not sure GHC runs there. > > > I'm using "word" in the GHC sense: > http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Word > > ie. it's the width of a pointer.
Aha, thanks! In that case, I would use uintptr_t in place of size_t just to make it plain clear (from documentation perspective) and to follow C standard semantics and idiomatic practice -- even if size_t and uintptr_t are likely to have the same width on "sane" platforms. For the corresponding printf-style format specifier, I would macro-test for PRIuPTR from <inttypes.h> and use it. It should be available on any modern computing system that GHC cares about. These types and macros have been there for nearly 15 years. -- Gaby _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
