[M3devel] rant -- Why has 64 bit integer support been so hard?

[Tony Hosking]

I think you have reasonably illustrated just why C/C++ is such a  
mess.  In M3 we have "BITS n FOR ..." to get appropriately sized  
things, equivalent to C/C++ char, short, long, long long.  The split  
between INTEGER and LONGINT is unfortunate perhaps, but represents an  
explicit signal to programmers that INTEGER and LONGINT have  
different underlying representations, which is in the spirit of  
Modula-3's existing type system.   Perhaps we should be explicit in  
the C type mappings for M3 by writing:

char = BITS 8 FOR ...
short = BITS 16 FOR ...
int = BITS 32 FOR ...
long_long = BITS 64 FOR ...

On Aug 11, 2007, at 10:26 AM, j k wrote:

> I know, like, the point of Modula-3 is to not be like C or C++ and  
> to revisit everything in them, but..really?
>
> Windows programming in C and C++ has had this solved reasonable for  
> MANY YEARS.
> Other folks solved it similarly even longer ago, though I would  
> claim Windows's
> approach has been successfully applied to more code -- that is, all  
> of Windows, and then some.
>
> Windows C/C++ is flawed here, but not in a too terrible way.
> In particular, Windows C/C++ has too many names for the same types,  
> with various
> flimsy rationale, mostly "style" and "history".
>
> All you need is the following:
>
>   signed and unsigned integer types that are exactly 8 bits in size
>   signed and unsigned integer types that are exactly 16 bits in size
>   signed and unsigned integer types that are exactly 32 bits in size
>   signed and unsigned integer types that are exactly 64 bits in size
>   signed and unsigned integer types that are exactly the size of a  
> pointer
>
>  10 integer types total, named something like:
>    INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64, size_t  
> or UINT_PTR, ptrdiff_t or INT_PTR
>
>  The types "int" and "long" and unsigned thereof NEVER changed size.
>  Where people were using them for pointer sized things, you would  
> do a simple transform to port to 64 bit:
>    int => INT => INT_PTR
>    unsigned => UINT => UINT_PTR
>    DWORD => DWORD_PTR
>
>   convert to the upper case types if not there, and append "_PTR"
>
>  The existing types size_t and ptrdiff_t did change size.
>   If someone really needed 32 bit types there, you'd have to change  
> your code.
>
>  Windows has more than that for historical and stylistics reasons  
> -- upper case types,
>    lowercase types, types that "favor" being unsigned int or  
> unsigned long.
>
>  Some of it is C's fault -- the "short" and "long" stuff seems all  
> unnecessary.
>
>  C 9x adds in "fast" and "small" types
>     types that are the smallest type that is at least a certain  
> size, I think
>     types that are the fastest type that are at least a certain  
> size, I think
>      the idea here being that if 64 bit integers are "faster" than  
> 32 bit integers, then "fast32" might be 64 bits
>
>  In reality, I think the 10 types are confusing enough, but  
> necessary, C9x multiplies out
>    beyond necessity. Yeah, obviously, they seem like maybe you  
> might want them, but
>    it's just too many times imho. Imho 8, 16, and 32 bit integers  
> must remain efficient
>    to use on all forseeable processors, since tons of code uses  
> them, and people should not
>    will not be pushed to widen everything across the board. Yeah,  
> 64K and 4GB limits are
>    mostly stupid these days and they very often should be widened,  
> but folks can do that
>    "slowly" on their own, managing compatibilit themselves -- like  
> where binary file i/o is used.
>
>   Why has this been so hard in Modula-3?
>
>   Is it that "Word" is widely used and has been pointer sized?
>   Or that INTEGER has been widely used and sometimes assumed to be  
> pointer sized?
>
>   Is it that Sparc64 (?) and 64 bit Alpha have existed for a long  
> time but
>     weren't done right and there is some legacy we are stuck with??
>
>   Do "subrange" types make it all confusing?
>
>   Or merely the assignment rules among the non subrange integer types?
>
>  I have not paid particularly close attention; it just has always  
> surprised me
>    that it was difficult to work out what to do.
>
>  I guess it is all moot now, the issues have been worked out and  
> the feature is there. Good.
>
>  I am skeptical that the name "LONGINT" is good. I am skeptical  
> that the slightly
>   abstracted C names "short", "int", "long" are a useful abstraction.
>   I think you really want the 10 base types I first listed.
>
> btw, even the types that are same size as a pointer are overused in  
> C/C++.
> You don't need them for as much pointer arithmetic as people use.  
> You can use "char*" for that.
> They are useful for array indices though, the result of wcslen,  
> sizeof(), etc.
>
> File sizes should always be UINT64..
>
>      - Jay
>
> Recharge--play some free games. Win cool prizes too! Play It!