www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 5063] New: Stronger typedef for size_t

reply d-bugmail puremagic.com writes:
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
next sibling parent d-bugmail puremagic.com writes:
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
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
prev sibling parent d-bugmail puremagic.com writes:
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:
 
 ...


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