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 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
