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

[Darko]

The point of M3 is not be different than some other language, the  
point is for it to be safe, and, as a side effect, easy to use.  
Making a language safe is hard becuase you have to consider every  
possible usage and outcome becuase the language guarantees that it  
will  not produce an "unchecked" error for the safe subset of the  
language, that is, it will do something random no matter how use use  
the language. So we have to consider all changes very carefully.


On 11/08/2007, at 4:26 PM, 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!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20070811/c69c6e9a/attachment-0005.html>