[Issue 5063] Stronger typedef for size_t

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=5063


Marco Leise <Marco.Leise at gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |Marco.Leise at gmx.de
         Resolution|WONTFIX                     |


--- Comment #3 from Marco Leise <Marco.Leise at gmx.de> 2013-06-08 00:45:10 PDT ---
I reopened this bug to extend the discussion a bit. This is a real issue in
writing portable code. I've tried to use a D library written on 32-bit that
wasn't usable because it mixed size_t and uint all over the place. Likewise I
tend to forget that file sized are ulong and store them in size_t variables,
making my 64-bit code not portable to 32-bit.

I think the compiler should at least warn about every implicit conversion
between size_t and (u)int/(u)long. The size_t -> ulong and uint -> size_t cases
being the only ones that should be silently allowed for consistency with the
other integral type conversions.

What are the difficulties in the implementation or the semantics?
Have any warnings been implemented recently that make this enhancement request
obsolete?

> Besides, it is perfectly legitimate to use an int to index an array on 64 bits.

That is besides the point of this enhancement request. When you have a uint
already from whatever source and your array is known to be < 2^32 it is of
course perfectly legitimate to do that.
But when you have a dynamic array and ask it for it's length you should be
reminded to store the result in a size_t or a ulong.
And the reverse example (which breaks coming from 64-bit to 32-bit):

struct S { size_t size; }
S s;
s.size = file.size();

Here the compiler should warn me that ulong != size_t as well.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------