size_t, size_t, wherefore art thou aliased?

[Hasan Aljudy]

I think I don't really understand the issue, but I'm gonna throw in my 2 
cents anyway ... even though it might sound pretty stupid:

Wouldn't a versioned alias declaration solve this?

version( X32 )
{
   alias something ...
}
version( X64 )
{
   alias something else ...
}

Gregor Richards wrote:
> (For the early-modern-English-impaired, "wherefore art thou aliased" 
> means "why are you aliased")
> 
> In the process of porting GDC to x86_64 (which has actually been 
> somewhat successful, but more on that later), I've discovered what I 
> consider to be a fairly significant problem.
> 
> Because size_t is aliased (and also partially because DDoc follows 
> aliases apparently), there is a tendency to use uint instead of size_t, 
> and no error or even feedback if you do!
> 
> For example, std.socketstream overrides:
> 
> size_t readBlock(void* _buffer, size_t size)
> 
> with
> 
> uint readBlock(void* _buffer, uint size)
> 
> Ouch!  Works fine on 32-bit systems, but totally fails on 64-bit 
> systems, and the writer has no way of knowing there's a bug until he 
> tries to compile it on a 64-bit system!  The biggest problem here is 
> with overriding (as in the above example), where it'll override properly 
> on 32-bit but improperly on 64-bit systems.
> 
> The folks on #d and I have created several possible solutions.
> 
> Our original thought was to make size_t (and ptrdiff_t) typedefs instead 
> of aliases - this would at least require no change to the language 
> proper.  Unfortunately, this makes assigning values to size_t and 
> ptrdiff_t obnoxious, since it only implicitly casts one way (not the way 
> that's helpful here).
> 
> Secondly, size_t and ptrdiff_t could be compiler-defined types, rather 
> than aliased types.  This would make the implicit casting come out 
> right, but is sort of ugly.
> 
> Finally, the preferred option seems to be a sort of weak typedef. 
> Basically, this would be a typedef, but with implicit casting both ways. 
>  So, [u]ints, [u]longs, size_ts and ptrdiff_ts would all play nicely 
> together, but overrides would not be happy if improperly defined.
> 
> The most unfortunate thing about this is that there's virtually no way 
> for a programmer on a 32-bit system to know when they've ran into a bug 
> like this.  Yuck.
> 
>  - Gregor Richards