[Issue 5063] New: Stronger typedef for size_t

Oct 16, 2010

bearophile_hugs@eml.cc

Oct 25, 2010

Walter Bright

Oct 26, 2010

Sobirari Muhomori

Jun 08, 2013

Marco Leise

Jun 11, 2013

Marco Leise

Jun 11, 2013

bearophile_hugs@eml.cc

http://d.puremagic.com/issues/show_bug.cgi?id=5063 Summary: Stronger typedef for size_t Product: D Version: D2 Platform: All OS/Version: All Status: NEW Keywords: accepts-invalid Severity: enhancement Priority: P2 Component: DMD AssignedTo: nobody@puremagic.com ReportedBy: bearophile_hugs@eml.cc --- Comment #0 from bearophile_hugs@eml.cc 2010-10-16 10:08:54 PDT --- It's better to design the D language to minimize the amount of changes (and pitfalls) needed to port 32 bit code to 64 bit. On 64 bit systems a size_t is 64 bit, while int/uint are 32 bit wide still. In D code I've seen this, that compiles with no errors: int i = array.length; But on 64 bit systems this code throws away half of the bits of the length, and I think the compiler doesn't allow that assignment without a cast. So in that assignment size_t=>int I suggest to raise a compile error on 32 bit systems too, so porting code from 32 to 64 bit doesn't require a change in that line of code. (Beside this one, there are few other situations where D2 may be changed to avoid some troubles caused by porting 32 bit code to 64 bit code. I'd like such other situations too to be addressed.) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5063 Walter Bright <bugzilla@digitalmars.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |bugzilla@digitalmars.com Resolution| |WONTFIX --- Comment #1 from Walter Bright <bugzilla@digitalmars.com> 2010-10-25 01:08:31 PDT --- Code that compiles on 32 bits but fails to compile on 64 bits with an appropriate message is not much of a problem. Making size_t its own type rather than an alias brings along a whole host of other problems. Besides, it is perfectly legitimate to use an int to index an array on 64 bits. Also, it is D best practice to rewrite: int i = array.length; as: auto i = array.length; unless one *specifically* requires an int. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5063 --- Comment #2 from Sobirari Muhomori <dfj1esp02@sneakemail.com> 2010-10-25 21:36:05 PDT --- This is not always possible. We also have fields and function parameters. ps I manage this bug by defining shorter aliases - intp and uintp. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------

June 08, 2013

[Issue 5063] Stronger typedef for size_t

Posted by Marco Leise
in reply to bearophile_hugs@eml.cc

Permalink

Marco Leise

Posted in reply to bearophile_hugs@eml.cc

Permalink

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


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

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


--- Comment #3 from Marco Leise <Marco.Leise@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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5063 --- Comment #5 from bearophile_hugs@eml.cc 2013-06-11 04:26:13 PDT --- (In reply to comment #4) > To back our point up a bit, here are some bug tickets that show up on a search for size_t: > > ... The D compiler here has enough static information to avoid future troubles in porting D code written on a 32 bit system to 64 bit systems. It's a good idea to use such information as much as possible. D has a static type system, so let's actually use it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------

Forums