digitalmars.D.bugs - [Issue 5063] New: Stronger typedef for size_t
- d-bugmail puremagic.com (30/30) Oct 16 2010 http://d.puremagic.com/issues/show_bug.cgi?id=5063
- d-bugmail puremagic.com (20/20) Oct 25 2010 http://d.puremagic.com/issues/show_bug.cgi?id=5063
- d-bugmail puremagic.com (7/7) Oct 25 2010 http://d.puremagic.com/issues/show_bug.cgi?id=5063
- d-bugmail puremagic.com (33/34) Jun 08 2013 http://d.puremagic.com/issues/show_bug.cgi?id=5063
- d-bugmail puremagic.com (24/24) Jun 11 2013 http://d.puremagic.com/issues/show_bug.cgi?id=5063
- d-bugmail puremagic.com (10/14) Jun 11 2013 http://d.puremagic.com/issues/show_bug.cgi?id=5063
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 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: -------
Oct 16 2010
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 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: -------
Oct 25 2010
http://d.puremagic.com/issues/show_bug.cgi?id=5063 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: -------
Oct 25 2010
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 | 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: -------
Jun 08 2013
http://d.puremagic.com/issues/show_bug.cgi?id=5063 To back our point up a bit, here are some bug tickets that show up on a search for size_t: dcollections: http://www.dsource.org/projects/dcollections/ticket/14 DWT: https://github.com/d-widget-toolkit/dwt/issues/2 https://github.com/d-widget-toolkit/dwt/issues/7 Tango: http://www.dsource.org/projects/tango/ticket/1817 http://www.dsource.org/projects/tango/ticket/1509 http://www.dsource.org/projects/tango/ticket/1443 http://www.dsource.org/projects/tango/ticket/1423 http://www.dsource.org/projects/tango/ticket/1422 http://www.dsource.org/projects/tango/ticket/1418 http://www.dsource.org/projects/tango/ticket/1417 http://www.dsource.org/projects/tango/ticket/1416 http://www.dsource.org/projects/tango/ticket/1415 http://www.dsource.org/projects/tango/ticket/1406 http://www.dsource.org/projects/tango/ticket/1303 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 11 2013
http://d.puremagic.com/issues/show_bug.cgi?id=5063To 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: -------
Jun 11 2013