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 agree that it's usually bad to use these uncertain types. It would be > nice to do a proper cleanup someday and purge them from the RTS. > > Cheers, > Simon _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
