www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - 'int' is enough for 'length' to migrate code from x86 to x64

reply "FrankLike" <1150015857 qq.com> writes:
If you migrate your projct from x86 to x64,you will find the 
length is error,you must modify it ,such as:
   int i= (something).length
to
   size_t i = (something).length

but now ,'int' is enough for use,not huge and not small,only 
enough.
'int' is easy to write,and most people are used to it.
Most importantly easier to migrate code,if  'length''s return 
value type is 'int'.

Thank you all.
Nov 18 2014
next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 18 Nov 2014 12:33:51 +0000
FrankLike via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 If you migrate your projct from x86 to x64,you will find the=20
 length is error,you must modify it ,such as:
    int i=3D (something).length
 to
    size_t i =3D (something).length
=20
 but now ,'int' is enough for use,not huge and not small,only=20
 enough.
 'int' is easy to write,and most people are used to it.
 Most importantly easier to migrate code,if  'length''s return=20
 value type is 'int'.
=20
 Thank you all.
drop your C. auto len =3D smth.length; works ok for both x86 and x86_64 (don't know what x64 is).
Nov 18 2014
next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Tuesday, 18 November 2014 at 13:35:46 UTC, ketmar via 
Digitalmars-d wrote:
 On Tue, 18 Nov 2014 12:33:51 +0000
 FrankLike via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 If you migrate your projct from x86 to x64,you will find the 
 length is error,you must modify it ,such as:
    int i= (something).length
 to
    size_t i = (something).length
 
 but now ,'int' is enough for use,not huge and not small,only 
 enough.
 'int' is easy to write,and most people are used to it.
 Most importantly easier to migrate code,if  'length''s return 
 value type is 'int'.
 
 Thank you all.
drop your C. auto len = smth.length; works ok for both x86 and x86_64 (don't know what x64 is).
x64 is commonly used by windows programmers to refer to x86_64 with a 64 bit OS.
Nov 18 2014
parent "FrankLike" <1150015857 qq.com> writes:
 but now ,'int' is enough for use,not huge and not small,only 
 enough.
 'int' is easy to write,and most people are used to it.
 Most importantly easier to migrate code,if  'length''s return 
 value type is 'int'.
How about your idea?
Nov 18 2014
prev sibling parent reply "FrankLike" <1150015857 qq.com> writes:
 drop your C.

   auto len = smth.length;

 works ok for both x86 and x86_64 (don't know what x64 is).
Many excellent projects such as dfl,dgui,tango, many 'length' which type is 'int' or 'uint',they are D's,many people like it.but they should migrate to 64 bit.So if 'length' type is 'int',they can work on 64 bit,but now,they must be modify for 'length''s type.
Nov 18 2014
next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 18 Nov 2014 14:24:16 +0000
FrankLike via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 drop your C.

   auto len =3D smth.length;

 works ok for both x86 and x86_64 (don't know what x64 is).
=20 Many excellent projects such as dfl,dgui,tango, many 'length'=20 which type is 'int' or 'uint',they are D's,many people like=20 it.but they should migrate to 64 bit.So if 'length' type is=20 'int',they can work on 64 bit,but now,they must be modify for=20 'length''s type.
broken code must be fixed by the authors of the broken code. that code is broken. authors must fix it.
Nov 18 2014
parent reply "FrankLike" <1150015857 qq.com> writes:
 Many excellent projects such as dfl,dgui,tango, many 'length' 
 which type is 'int' or 'uint',they are D's,many people like 
 it.but they should migrate to 64 bit.So if 'length' type is 
 'int',they can work on 64 bit,but now,they must be modify for 
 'length''s type.
broken code must be fixed by the authors of the broken code. that code is broken. authors must fix it.
Now,dfl's anthor miller has stopped updating the dfl project,and dgui also was.But they are excellent,we like to use it.
Nov 18 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 18 Nov 2014 14:41:18 +0000
FrankLike via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 Many excellent projects such as dfl,dgui,tango, many 'length'=20
 which type is 'int' or 'uint',they are D's,many people like=20
 it.but they should migrate to 64 bit.So if 'length' type is=20
 'int',they can work on 64 bit,but now,they must be modify for=20
 'length''s type.
broken code must be fixed by the authors of the broken code.=20 that code is broken. authors must fix it.
=20 Now,dfl's anthor miller has stopped updating the dfl project,and=20 dgui also was.But they are excellent,we like to use it.
fork 'em and fix 'em. if nobody wants to fix the project, the project is dead and should be not used, obviously.
Nov 18 2014
parent reply "Frank Like" <1150015857 qq.com> writes:
 but now ,'int' is enough for use,not huge and not small,only 
 enough.
 'int' is easy to write,and most people are used to it.
 Most importantly easier to migrate code,if  'length''s return
value type is 'int'.
How about your idea?
Nov 18 2014
parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Tue, 18 Nov 2014 15:01:25 +0000
schrieb "Frank Like" <1150015857 qq.com>:

 but now ,'int' is enough for use,not huge and not small,only=20
 enough.
 'int' is easy to write,and most people are used to it.
 Most importantly easier to migrate code,if  'length''s return
value type is 'int'.
=20 How about your idea?
I get the idea of a broken record right now... Clearly size_t (which I tend to alias with =E2=84=95 in my code for brevity and coolness) can express more than 2^31-1 items, which is appropriate to reflect the increase in usable memory per application on 64-bit platforms. Yes, the 64-bit version of a program or library can handle larger data sets. Just like it was when people transitioned from 16-bit to 32-bit. I wont use `int` just because the technically correct thing is `size_t`, even it it is a little harder to type. Aside from the size factor, I personally prefer unsigned types for countable stuff like array lengths. Mixed arithmetics decay to unsinged anyways and you don't need checks like `assert(idx >=3D 0)`. It is a matter of taste though and others prefer languages with no unsigned types at all. --=20 Marco
Nov 18 2014
next sibling parent reply "Frank Like" <1150015857 qq.com> writes:
 Clearly size_t (which I tend to alias with ℕ in my code for
 brevity and coolness) can express more than 2^31-1 items, which
 is appropriate to reflect the increase in usable memory per
 application on 64-bit platforms. Yes, the 64-bit version of a
 program or library can handle larger data sets. Just like it
I known it. but if you compile the dfl Library to 64 bit,you will find error: core.sys.windows.windows.WaitForMultipleObjects(uint nCount,void** lpHandles,....) is not callable using argument types(ulong,void**,...) the 'WaitForMultipleObjects' Function is in dmd2/src/druntime/src/core/sys/windows/windows.d the argument of first is dfl's value ,it come from a 'length' ,it's type is size_t,now it is 'ulong' on 64 bit. So druntime must keep the same as phobos for size_t.
Nov 19 2014
parent reply "Dominikus Dittes Scherkl" writes:
On Wednesday, 19 November 2014 at 09:06:16 UTC, Maroc Leise wrote:
 Clearly size_t (which I tend to alias with ℕ in my code for
 brevity and coolness)
No, this is far from the implied infinite set. A much better candidate for ℕ is BigUInt (and ℤ for BigInt)
Nov 19 2014
parent Marco Leise <Marco.Leise gmx.de> writes:
Am Wed, 19 Nov 2014 10:22:49 +0000
schrieb "Dominikus Dittes Scherkl"
<Dominikus.Scherkl continental-corporation.com>:

 On Wednesday, 19 November 2014 at 09:06:16 UTC, Maroc Leise wrote:
 Clearly size_t (which I tend to alias with =E2=84=95 in my code for
 brevity and coolness)
No, this is far from the implied infinite set. A much better candidate for =E2=84=95 is BigUInt (and =E2=84=A4 for BigIn=
t) How far exactly is it from infinity? And how much closer is BigInt? I wanted a fast =E2=84=95 within the constraints of the machine. ;) --=20 Marco
Nov 21 2014
prev sibling next sibling parent reply "Don" <x nospam.com> writes:
On Tuesday, 18 November 2014 at 18:23:52 UTC, Marco Leise wrote:
 Am Tue, 18 Nov 2014 15:01:25 +0000
 schrieb "Frank Like" <1150015857 qq.com>:

 but now ,'int' is enough for use,not huge and not small,only 
 enough.
 'int' is easy to write,and most people are used to it.
 Most importantly easier to migrate code,if  'length''s return
value type is 'int'.
How about your idea?
I get the idea of a broken record right now... Clearly size_t (which I tend to alias with ℕ in my code for brevity and coolness) can express more than 2^31-1 items, which is appropriate to reflect the increase in usable memory per application on 64-bit platforms. Yes, the 64-bit version of a program or library can handle larger data sets. Just like it was when people transitioned from 16-bit to 32-bit. I wont use `int` just because the technically correct thing is `size_t`, even it it is a little harder to type.
This is difficult. Having arr.length return an unsigned type, is a dreadful language mistake.
 Aside from the size factor, I personally prefer unsigned types
 for countable stuff like array lengths. Mixed arithmetics
 decay to unsinged anyways and you don't need checks like
 `assert(idx >= 0)`. It is a matter of taste though and others
 prefer languages with no unsigned types at all.
No! No! No! This is completely wrong. Unsigned does not mean "positive". It means "no sign", and therefore "wrapping semantics". eg length - 4 > 0, if length is 2. Weird consequence: using subtraction with an unsigned type is nearly always a bug. I wish D hadn't called unsigned integers 'uint'. They should have been called '__uint' or something. They should look ugly. You need a very, very good reason to use an unsigned type. We have a builtin type that is deadly but seductive.
Nov 19 2014
next sibling parent reply "Matthias Bentrup" <matthias.bentrup googlemail.com> writes:
On Wednesday, 19 November 2014 at 10:03:35 UTC, Don wrote:
 On Tuesday, 18 November 2014 at 18:23:52 UTC, Marco Leise wrote:
 Am Tue, 18 Nov 2014 15:01:25 +0000
 schrieb "Frank Like" <1150015857 qq.com>:

 but now ,'int' is enough for use,not huge and not 
 small,only enough.
 'int' is easy to write,and most people are used to it.
 Most importantly easier to migrate code,if  'length''s 
 return
value type is 'int'.
How about your idea?
I get the idea of a broken record right now... Clearly size_t (which I tend to alias with ℕ in my code for brevity and coolness) can express more than 2^31-1 items, which is appropriate to reflect the increase in usable memory per application on 64-bit platforms. Yes, the 64-bit version of a program or library can handle larger data sets. Just like it was when people transitioned from 16-bit to 32-bit. I wont use `int` just because the technically correct thing is `size_t`, even it it is a little harder to type.
This is difficult. Having arr.length return an unsigned type, is a dreadful language mistake.
 Aside from the size factor, I personally prefer unsigned types
 for countable stuff like array lengths. Mixed arithmetics
 decay to unsinged anyways and you don't need checks like
 `assert(idx >= 0)`. It is a matter of taste though and others
 prefer languages with no unsigned types at all.
No! No! No! This is completely wrong. Unsigned does not mean "positive". It means "no sign", and therefore "wrapping semantics". eg length - 4 > 0, if length is 2. Weird consequence: using subtraction with an unsigned type is nearly always a bug. I wish D hadn't called unsigned integers 'uint'. They should have been called '__uint' or something. They should look ugly. You need a very, very good reason to use an unsigned type. We have a builtin type that is deadly but seductive.
int has wrapping the same semantics too, only it wraps to negative numbers instead of zero. If you insist on non-wrapping length, it should return double or long double.
Nov 19 2014
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Wednesday, 19 November 2014 at 11:04:05 UTC, Matthias Bentrup 
wrote:
 On Wednesday, 19 November 2014 at 10:03:35 UTC, Don wrote:
 On Tuesday, 18 November 2014 at 18:23:52 UTC, Marco Leise 
 wrote:
 Am Tue, 18 Nov 2014 15:01:25 +0000
 schrieb "Frank Like" <1150015857 qq.com>:

 but now ,'int' is enough for use,not huge and not 
 small,only enough.
 'int' is easy to write,and most people are used to it.
 Most importantly easier to migrate code,if  'length''s 
 return
value type is 'int'.
How about your idea?
I get the idea of a broken record right now... Clearly size_t (which I tend to alias with ℕ in my code for brevity and coolness) can express more than 2^31-1 items, which is appropriate to reflect the increase in usable memory per application on 64-bit platforms. Yes, the 64-bit version of a program or library can handle larger data sets. Just like it was when people transitioned from 16-bit to 32-bit. I wont use `int` just because the technically correct thing is `size_t`, even it it is a little harder to type.
This is difficult. Having arr.length return an unsigned type, is a dreadful language mistake.
 Aside from the size factor, I personally prefer unsigned types
 for countable stuff like array lengths. Mixed arithmetics
 decay to unsinged anyways and you don't need checks like
 `assert(idx >= 0)`. It is a matter of taste though and others
 prefer languages with no unsigned types at all.
No! No! No! This is completely wrong. Unsigned does not mean "positive". It means "no sign", and therefore "wrapping semantics". eg length - 4 > 0, if length is 2. Weird consequence: using subtraction with an unsigned type is nearly always a bug. I wish D hadn't called unsigned integers 'uint'. They should have been called '__uint' or something. They should look ugly. You need a very, very good reason to use an unsigned type. We have a builtin type that is deadly but seductive.
int has wrapping the same semantics too, only it wraps to negative numbers instead of zero. If you insist on non-wrapping length, it should return double or long double.
Which would be totally wrong for different reasons. Short of BigInts or overflow-checking, there is no perfect option. An overflow-checked type that could be reasonably well optimised would be nice, as mentioned by bearophile many times.
Nov 19 2014
parent reply "Don" <x nospam.com> writes:
On Wednesday, 19 November 2014 at 11:43:38 UTC, John Colvin wrote:
 On Wednesday, 19 November 2014 at 11:04:05 UTC, Matthias 
 Bentrup wrote:
 On Wednesday, 19 November 2014 at 10:03:35 UTC, Don wrote:
 On Tuesday, 18 November 2014 at 18:23:52 UTC, Marco Leise 
 wrote:
 Am Tue, 18 Nov 2014 15:01:25 +0000
 schrieb "Frank Like" <1150015857 qq.com>:

 but now ,'int' is enough for use,not huge and not 
 small,only enough.
 'int' is easy to write,and most people are used to it.
 Most importantly easier to migrate code,if  'length''s 
 return
value type is 'int'.
How about your idea?
I get the idea of a broken record right now... Clearly size_t (which I tend to alias with ℕ in my code for brevity and coolness) can express more than 2^31-1 items, which is appropriate to reflect the increase in usable memory per application on 64-bit platforms. Yes, the 64-bit version of a program or library can handle larger data sets. Just like it was when people transitioned from 16-bit to 32-bit. I wont use `int` just because the technically correct thing is `size_t`, even it it is a little harder to type.
This is difficult. Having arr.length return an unsigned type, is a dreadful language mistake.
 Aside from the size factor, I personally prefer unsigned 
 types
 for countable stuff like array lengths. Mixed arithmetics
 decay to unsinged anyways and you don't need checks like
 `assert(idx >= 0)`. It is a matter of taste though and others
 prefer languages with no unsigned types at all.
No! No! No! This is completely wrong. Unsigned does not mean "positive". It means "no sign", and therefore "wrapping semantics". eg length - 4 > 0, if length is 2. Weird consequence: using subtraction with an unsigned type is nearly always a bug. I wish D hadn't called unsigned integers 'uint'. They should have been called '__uint' or something. They should look ugly. You need a very, very good reason to use an unsigned type. We have a builtin type that is deadly but seductive.
int has wrapping the same semantics too, only it wraps to negative numbers instead of zero.
No. Signed types do not *wrap*. They *overflow* if their range is exceeded. This is not the same thing. Overflow is always an error. And the compiler could insert checks to detect this. That's not possible for unsigned types. With an unsigned type, wrapping is part of the semantics. Moreover, hitting an overflow with a signed type is an exceptional situation. Wrapping with an unsigned type is entirely normal, and happens with things like 2u - 1u.
If you insist on
 non-wrapping length, it should return double or long double.
Which would be totally wrong for different reasons. Short of BigInts or overflow-checking, there is no perfect option. An overflow-checked type that could be reasonably well optimised would be nice, as mentioned by bearophile many times.
I don't think we need to worry about the pathological cases. The problem with unsigned size_t is that it introduces inappropriate semantics everywhere for the sake of the pathological cases. IMHO the correct solution is to say that the length of a slice cannot exceed half of the memory space, otherwise a runtime error will occur. And then make size_t a positive integer. Then let typeof(size_t - size_t) == int, instead of uint. All other operations stay as size_t. Perhaps we can get most of the way, by improving range propagation.
Nov 19 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 19 Nov 2014 13:33:21 +0000
Don via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 No. Signed types do not *wrap*. They *overflow* if their range is=20
 exceeded.
same for unsigned ints.
 This is not the same thing. Overflow is always an error.
 And the compiler could insert checks to detect this.
and for unsigned ints. i want compilers to has special code for this. something like `checkedInt(...)`. and this must be built-in, 'cause checking carry flag is cheap, but can be done only on "machine" level.
 That's not possible for unsigned types. With an unsigned type,=20
 wrapping is part of the semantics.
see above.
 Moreover, hitting an overflow with a signed type is an=20
 exceptional situation. Wrapping with an unsigned type is entirely=20
 normal, and happens with things like 2u - 1u.
having results of unsigned int wrapping defined doesn't mean that it's "normal". it's just *defined*, so you can check for it without triggering UB.
 IMHO the correct solution is to say that the length of a slice=20
 cannot exceed half of the memory space, otherwise a runtime error=20
 will occur. And then make size_t a positive integer.
but why? maybe 1/3 of address space fits better? or 256 bytes, to really avoid "overflows" and "wrapping"?
 Then let typeof(size_t - size_t) =3D=3D int, instead of uint. All=20
 other operations stay as size_t.
check and cast. you can check length and then safely cast it to int, no probs.
Nov 19 2014
parent reply "Don" <x nospam.com> writes:
On Wednesday, 19 November 2014 at 13:47:31 UTC, ketmar via 
Digitalmars-d wrote:
 On Wed, 19 Nov 2014 13:33:21 +0000
 Don via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 No. Signed types do not *wrap*. They *overflow* if their range 
 is exceeded.
same for unsigned ints.
 This is not the same thing. Overflow is always an error.
 And the compiler could insert checks to detect this.
and for unsigned ints. i want compilers to has special code for this. something like `checkedInt(...)`. and this must be built-in, 'cause checking carry flag is cheap, but can be done only on "machine" level.
I don't know what you mean. For unsigned ints, carry is not an error. That's the whole point of unsigned!
 That's not possible for unsigned types. With an unsigned type,
 wrapping is part of the semantics.
see above.
 Moreover, hitting an overflow with a signed type is an 
 exceptional situation. Wrapping with an unsigned type is 
 entirely normal, and happens with things like 2u - 1u.
having results of unsigned int wrapping defined doesn't mean that it's "normal". it's just *defined*, so you can check for it without triggering UB.
 IMHO the correct solution is to say that the length of a slice 
 cannot exceed half of the memory space, otherwise a runtime 
 error will occur. And then make size_t a positive integer.
but why? maybe 1/3 of address space fits better? or 256 bytes, to really avoid "overflows" and "wrapping"?
No. The point is to get correct semantics. Unsigned types do not have the correct semantics. Signed types do.
 Then let typeof(size_t - size_t) == int, instead of uint. All 
 other operations stay as size_t.
check and cast. you can check length and then safely cast it to int, no probs.
This is the job of the compiler, not the programmer. The compiler should do this at all possible places where a slice could exceed the int.max / long.max. That's cheap because there are hardly any places it could happen (for example, for array slices it can only happen with 1-byte types). --- Almost everybody seems to think that unsigned means positive. It does not. ---
Nov 19 2014
next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 19 Nov 2014 14:04:15 +0000
Don via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 I don't know what you mean. For unsigned ints, carry is not an=20
 error. That's the whole point of unsigned!
this *may* be not a error. it depends of what programmer wants.
 This is the job of the compiler, not the programmer. The compiler=20
 should do this at all possible places where a slice could exceed=20
 the int.max / long.max. That's cheap because there are hardly any=20
 places it could happen (for example, for array slices it can only=20
 happen with 1-byte types).
i, for myself, don't want the compiler to do arcane type conversions behind my back.
 ---
 Almost everybody seems to think that unsigned means positive. It=20
 does not.
 ---
sure, it includes zero, which is neither positive nor negative. ;-)
Nov 19 2014
prev sibling next sibling parent "Matthias Bentrup" <matthias.bentrup googlemail.com> writes:
On Wednesday, 19 November 2014 at 14:04:16 UTC, Don wrote:
 No. The point is to get correct semantics. Unsigned types do 
 not have the correct semantics. Signed types do.
In D both signed and unsigned integers have defined wrapping semantincs. In C++ signed integers are allowed to format your harddisk on overflow.
Nov 19 2014
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/19/14 6:04 AM, Don wrote:
 Almost everybody seems to think that unsigned means positive. It does not.
That's an exaggeration. With only a bit of care one can use D's unsigned types for positive numbers. Please let's not reduce the matter to black and white. Andrei
Nov 19 2014
parent reply "Don" <x nospam.com> writes:
On Wednesday, 19 November 2014 at 17:55:26 UTC, Andrei 
Alexandrescu wrote:
 On 11/19/14 6:04 AM, Don wrote:
 Almost everybody seems to think that unsigned means positive. 
 It does not.
That's an exaggeration. With only a bit of care one can use D's unsigned types for positive numbers. Please let's not reduce the matter to black and white. Andrei
Even in the responses in this thread indicate that about half of the people here don't understand unsigned. "unsigned" means "I want to use modulo 2^^n arithmetic". It does not mean, "this is an integer which cannot be negative". Using modulo 2^^n arithmetic is *weird*. If you are using uint/ulong to represent a non-negative integer, you are using the incorrect type.
 "With only a bit of care one can use D's unsigned types for 
 positive numbers."
I do not believe that that statement to be true. I believe that bugs caused by unsigned calculations are subtle and require an extraordinary level of diligence. I showed an example at DConf, that I had found in production code. It's particularly challenging in D because of the widespread use of 'auto': auto x = foo(); auto y = bar(); auto z = baz(); if (x - y > z) { ... } This might be a bug, if one of these functions returns an unsigned type. Good luck finding that. Note that if all functions return unsigned, there isn't even any signed-unsigned mismatch. I believe the correct statement, is "With only a bit of care one can use D's unsigned types for positive numbers and believe that one's code is correct, even though it contains subtle bugs."
Nov 20 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/20/14 12:18 AM, Don wrote:
 On Wednesday, 19 November 2014 at 17:55:26 UTC, Andrei Alexandrescu wrote:
 On 11/19/14 6:04 AM, Don wrote:
 Almost everybody seems to think that unsigned means positive. It does
 not.
That's an exaggeration. With only a bit of care one can use D's unsigned types for positive numbers. Please let's not reduce the matter to black and white. Andrei
Even in the responses in this thread indicate that about half of the people here don't understand unsigned. "unsigned" means "I want to use modulo 2^^n arithmetic". It does not mean, "this is an integer which cannot be negative". Using modulo 2^^n arithmetic is *weird*. If you are using uint/ulong to represent a non-negative integer, you are using the incorrect type.
 "With only a bit of care one can use D's unsigned types for positive
 numbers."
I do not believe that that statement to be true. I believe that bugs caused by unsigned calculations are subtle and require an extraordinary level of diligence. I showed an example at DConf, that I had found in production code. It's particularly challenging in D because of the widespread use of 'auto': auto x = foo(); auto y = bar(); auto z = baz(); if (x - y > z) { ... } This might be a bug, if one of these functions returns an unsigned type. Good luck finding that. Note that if all functions return unsigned, there isn't even any signed-unsigned mismatch. I believe the correct statement, is "With only a bit of care one can use D's unsigned types for positive numbers and believe that one's code is correct, even though it contains subtle bugs."
Well I'm sorry but I quite disagree. -- Andrei
Nov 20 2014
next sibling parent reply "FrankLike" <1150015857 qq.com> writes:
 auto x = foo();
 auto y = bar();
 auto z = baz();

 if (x - y > z) { ... }


 This might be a bug, if one of these functions returns an 
 unsigned
 type.  Good luck finding that. Note that if all functions 
 return
 unsigned, there isn't even any signed-unsigned mismatch.

 I believe the correct statement, is "With only a bit of care 
 one can use
 D's unsigned types for positive numbers and believe that one's 
 code is
 correct, even though it contains subtle bugs."
Well I'm sorry but I quite disagree. -- Andrei
This might be a bug. 'Length' always needs to compare sizes. 'Width' and 'Height' like it. ************************ dfl/drawing.d line:185 -218 ************************** /// Size opAdd(Size sz) { Size result; result.width = width + sz.width; result.height = height + sz.height; return result; } /// Size opSub(Size sz) { Size result; result.width = width - sz.width; result.height = height - sz.height; return result; } /// void opAddAssign(Size sz) { width += sz.width; height += sz.height; } /// void opSubAssign(Size sz) { width -= sz.width; height -= sz.height; } ***********************end************************* if the type of width and height are size_t,then their values will be error. small test: ----------------------- import std.stdio; void main() { size_t width = 10; size_t height = 20; writeln("before width is ",width," ,height is ",height); height -= 1; width -= height; writeln("after width is ",width," ,height is ",height); } ---------- "after width is " ERROR.
Nov 20 2014
parent "Matthias Bentrup" <matthias.bentrup googlemail.com> writes:
On Thursday, 20 November 2014 at 13:26:23 UTC, FrankLike wrote:
 auto x = foo();
 auto y = bar();
 auto z = baz();

 if (x - y > z) { ... }


 This might be a bug, if one of these functions returns an 
 unsigned
 type.  Good luck finding that. Note that if all functions 
 return
 unsigned, there isn't even any signed-unsigned mismatch.

 I believe the correct statement, is "With only a bit of care 
 one can use
 D's unsigned types for positive numbers and believe that 
 one's code is
 correct, even though it contains subtle bugs."
Well I'm sorry but I quite disagree. -- Andrei
This might be a bug. 'Length' always needs to compare sizes. 'Width' and 'Height' like it. ************************ dfl/drawing.d line:185 -218 ************************** /// Size opAdd(Size sz) { Size result; result.width = width + sz.width; result.height = height + sz.height; return result; } /// Size opSub(Size sz) { Size result; result.width = width - sz.width; result.height = height - sz.height; return result; } /// void opAddAssign(Size sz) { width += sz.width; height += sz.height; } /// void opSubAssign(Size sz) { width -= sz.width; height -= sz.height; } ***********************end************************* if the type of width and height are size_t,then their values will be error. small test: ----------------------- import std.stdio; void main() { size_t width = 10; size_t height = 20; writeln("before width is ",width," ,height is ",height); height -= 1; width -= height; writeln("after width is ",width," ,height is ",height); } ---------- "after width is " ERROR.
I get "after width is 18446744073709551607 ,height is 19", which looks mathematically correct to me.
Nov 20 2014
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 11/20/14, 6:47 AM, Andrei Alexandrescu wrote:
 On 11/20/14 12:18 AM, Don wrote:
 On Wednesday, 19 November 2014 at 17:55:26 UTC, Andrei Alexandrescu
 wrote:
 On 11/19/14 6:04 AM, Don wrote:
 Almost everybody seems to think that unsigned means positive. It does
 not.
That's an exaggeration. With only a bit of care one can use D's unsigned types for positive numbers. Please let's not reduce the matter to black and white. Andrei
Even in the responses in this thread indicate that about half of the people here don't understand unsigned. "unsigned" means "I want to use modulo 2^^n arithmetic". It does not mean, "this is an integer which cannot be negative". Using modulo 2^^n arithmetic is *weird*. If you are using uint/ulong to represent a non-negative integer, you are using the incorrect type.
 "With only a bit of care one can use D's unsigned types for positive
 numbers."
I do not believe that that statement to be true. I believe that bugs caused by unsigned calculations are subtle and require an extraordinary level of diligence. I showed an example at DConf, that I had found in production code. It's particularly challenging in D because of the widespread use of 'auto': auto x = foo(); auto y = bar(); auto z = baz(); if (x - y > z) { ... } This might be a bug, if one of these functions returns an unsigned type. Good luck finding that. Note that if all functions return unsigned, there isn't even any signed-unsigned mismatch. I believe the correct statement, is "With only a bit of care one can use D's unsigned types for positive numbers and believe that one's code is correct, even though it contains subtle bugs."
Well I'm sorry but I quite disagree. -- Andrei
I don't think disagreeing without a reason (like the one Don gave above) is good. You could show us the benefits of unsigned types over signed types (possibly considering that not every program in the world needs an array with 2^64 elements).
Nov 20 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/20/14 6:20 AM, Ary Borenszweig wrote:
 On 11/20/14, 6:47 AM, Andrei Alexandrescu wrote:
 On 11/20/14 12:18 AM, Don wrote:
 On Wednesday, 19 November 2014 at 17:55:26 UTC, Andrei Alexandrescu
 wrote:
 On 11/19/14 6:04 AM, Don wrote:
 Almost everybody seems to think that unsigned means positive. It does
 not.
That's an exaggeration. With only a bit of care one can use D's unsigned types for positive numbers. Please let's not reduce the matter to black and white. Andrei
Even in the responses in this thread indicate that about half of the people here don't understand unsigned. "unsigned" means "I want to use modulo 2^^n arithmetic". It does not mean, "this is an integer which cannot be negative". Using modulo 2^^n arithmetic is *weird*. If you are using uint/ulong to represent a non-negative integer, you are using the incorrect type.
 "With only a bit of care one can use D's unsigned types for positive
 numbers."
I do not believe that that statement to be true. I believe that bugs caused by unsigned calculations are subtle and require an extraordinary level of diligence. I showed an example at DConf, that I had found in production code. It's particularly challenging in D because of the widespread use of 'auto': auto x = foo(); auto y = bar(); auto z = baz(); if (x - y > z) { ... } This might be a bug, if one of these functions returns an unsigned type. Good luck finding that. Note that if all functions return unsigned, there isn't even any signed-unsigned mismatch. I believe the correct statement, is "With only a bit of care one can use D's unsigned types for positive numbers and believe that one's code is correct, even though it contains subtle bugs."
Well I'm sorry but I quite disagree. -- Andrei
I don't think disagreeing without a reason (like the one Don gave above) is good.
Most of the statements I disagreed with were opinions.
 "unsigned" means "I want to use modulo 2^^n arithmetic". It does
 not mean, "this is an integer which cannot be negative".
Opinion.
 Using modulo 2^^n arithmetic is *weird*.
Opinion.
 If you are using
 uint/ulong to represent a non-negative integer, you are using the
 incorrect type.
Opinion.
 I believe that
 bugs caused by unsigned calculations are subtle and require an
 extraordinary level of diligence.
Opinion (correctly qualified as belief). Andrei
Nov 20 2014
parent reply "Araq" <rumpf_a web.de> writes:
 Most of the statements I disagreed with were opinions.

 "unsigned" means "I want to use modulo 2^^n arithmetic". It 
 does
 not mean, "this is an integer which cannot be negative".
Opinion.
 Using modulo 2^^n arithmetic is *weird*.
Opinion.
 If you are using
 uint/ulong to represent a non-negative integer, you are 
 using the
 incorrect type.
Opinion.
 I believe that
 bugs caused by unsigned calculations are subtle and require 
 an
 extraordinary level of diligence.
Opinion (correctly qualified as belief).
It's not only his "opinion", it's his *experience* and if we want to play the "argument by authority" game: he most likely wrote more production quality code in D than you did. Here are some more "opinions": http://critical.eschertech.com/2010/04/07/danger-unsigned-types-used-here/
Nov 20 2014
next sibling parent reply "flamencofantasy" <flamencofantasy gmail.com> writes:
On Thursday, 20 November 2014 at 15:40:40 UTC, Araq wrote:
 Most of the statements I disagreed with were opinions.

 "unsigned" means "I want to use modulo 2^^n arithmetic". It 
 does
 not mean, "this is an integer which cannot be negative".
Opinion.
 Using modulo 2^^n arithmetic is *weird*.
Opinion.
 If you are using
 uint/ulong to represent a non-negative integer, you are 
 using the
 incorrect type.
Opinion.
 I believe that
 bugs caused by unsigned calculations are subtle and require 
 an
 extraordinary level of diligence.
Opinion (correctly qualified as belief).
It's not only his "opinion", it's his *experience* and if we want to play the "argument by authority" game: he most likely wrote more production quality code in D than you did. Here are some more "opinions": http://critical.eschertech.com/2010/04/07/danger-unsigned-types-used-here/
My experience is totally the opposite of his. I have been using unsigned for lengths, widths, heights for the past 15 years in C, C++, C# and more recently in D with great success. I don't pretend to be any kind of authority though. The article you point to is totally flawed and kinda wasteful in terms of having to read it; the very first code snippet is obviously buggy. You can't purposefully write buggy code and then comment on the dangers of this or that! size_t i; for (i = size - 1; i >= 0; --i) { If you that's subtle to you then yes, use signed!
Nov 20 2014
parent reply "Kagamin" <spam here.lot> writes:
On Thursday, 20 November 2014 at 16:34:12 UTC, flamencofantasy 
wrote:
 My experience is totally the opposite of his. I have been using 
 unsigned for lengths, widths, heights for the past 15 years in 
 C, C++, C# and more recently in D with great success. I don't 
 pretend to be any kind of authority though.
C# doesn't encourage usage of unsigned types and warns that they are not CLS-compliant. You're going against established practices there. And signed types for numbers works wonders in C# without any notable problem and makes reasoning about code easier as you don't have to manually check for unsigned conversion bugs everywhere.
 The article you point to is totally flawed and kinda wasteful 
 in terms of having to read it; the very first code snippet is 
 obviously buggy.
That's the whole point: mixing signed with unsigned is bug-prone. Worse, it's inevitable if you force unsigned types everywhere.
Nov 21 2014
next sibling parent reply "FrankLike" <1150015857 qq.com> writes:
On Friday, 21 November 2014 at 09:43:04 UTC, Kagamin wrote:
 On Thursday, 20 November 2014 at 16:34:12 UTC, flamencofantasy
 C# doesn't encourage usage of unsigned types and warns that 
 they are not CLS-compliant. You're going against established 
 practices there. And signed types for numbers works wonders in 
 C# without any notable problem and makes reasoning about code 
 easier as you don't have to manually check for unsigned 
 conversion bugs everywhere.
 That's the whole point: mixing signed with unsigned is 
 bug-prone. Worse, it's inevitable if you force unsigned types 
 everywhere.
Right. Druntime should have a checksize_t.d.... Frank
Nov 21 2014
parent "FrankLike" <1150015857 qq.com> writes:
  Druntime's checkint.d  should be modify:

  uint subu(uint x, uint y, ref bool overflow)
{
     if (x < y)
       return y - x;
      else
       return x - y;
}

  uint subu(ulong x, ulong y, ref bool overflow)
{
     if (x < y)
       return y - x;
      else
       return x - y;
}


Frank
Nov 21 2014
prev sibling parent "flamencofantasy" <flamencofantasy gmail.com> writes:
On Friday, 21 November 2014 at 09:43:04 UTC, Kagamin wrote:

 C# doesn't encourage usage of unsigned types and warns that 
 they are not CLS-compliant. You're going against established 
 practices there. And signed types for numbers works wonders in 
 C# without any notable problem and makes reasoning about code 
 easier as you don't have to manually check for unsigned 
 conversion bugs everywhere.
I don't want to be CLS compliant! I make very heavy use of unsafe code, stackalloc and interop to worry about CLS compliance. Actually one of the major reasons I am looking at D for production code is so that I don't have to mix and match Assembly, C/C++ with C#. I want the best of all worlds in one language/runtime :). Anyways, I believe the discussion is about using unsigned for array lengths, not unsigned in general. At this point most people seem to express an opinion - including me, and I certainly hope D stays as it is when it comes to length of an array. I am not convinced in the slightest that signed is the way to go.
Nov 21 2014
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 20 November 2014 at 15:40:40 UTC, Araq wrote:
 Most of the statements I disagreed with were opinions.

 "unsigned" means "I want to use modulo 2^^n arithmetic". It 
 does
 not mean, "this is an integer which cannot be negative".
Opinion.
 Using modulo 2^^n arithmetic is *weird*.
Opinion.
 If you are using
 uint/ulong to represent a non-negative integer, you are 
 using the
 incorrect type.
Opinion.
 I believe that
 bugs caused by unsigned calculations are subtle and require 
 an
 extraordinary level of diligence.
Opinion (correctly qualified as belief).
It's not only his "opinion", it's his *experience* and if we want to play the "argument by authority" game: he most likely wrote more production quality code in D than you did.
Urrmmm, really? Andrei has written a hell of a lot of production quality code. I use it every day, in production, as do many others.
Nov 20 2014
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/20/14 7:40 AM, Araq wrote:
 It's not only his "opinion", it's his *experience*
Yes, there's some good anecdotal evidence too. IMHO not enough to trigger a change to other solutions that have their own issues. -- Andrei
Nov 20 2014
prev sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 20 Nov 2014 15:40:39 +0000
Araq via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 Here are some more "opinions":
 http://critical.eschertech.com/2010/04/07/danger-unsigned-types-used-here/
trying to illustrate something with obviously wrong code is very funny. the whole article then reduces to "hey, i'm writing bad code, and i can teach you to do the same!" won't buy it.
Nov 21 2014
prev sibling next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Nov 20, 2014 at 08:18:23AM +0000, Don via Digitalmars-d wrote:
 On Wednesday, 19 November 2014 at 17:55:26 UTC, Andrei Alexandrescu wrote:
On 11/19/14 6:04 AM, Don wrote:
Almost everybody seems to think that unsigned means positive. It
does not.
That's an exaggeration. With only a bit of care one can use D's unsigned types for positive numbers. Please let's not reduce the matter to black and white. Andrei
Even in the responses in this thread indicate that about half of the people here don't understand unsigned. "unsigned" means "I want to use modulo 2^^n arithmetic". It does not mean, "this is an integer which cannot be negative". Using modulo 2^^n arithmetic is *weird*. If you are using uint/ulong to represent a non-negative integer, you are using the incorrect type.
[...] By that logic, using an int to represent an integer is also using the incorrect type, because a signed type is *also* subject to module 2^^n arithmetic -- just a different form of it where the most negative value wraps around to the most positive values. Fixed-width integers in computing are NOT the same thing as unrestricted integers in mathematics. No matter how you try to rationalize it, as long as you use hardware fix-width "integers", you're dealing with modulo arithmetic in one form or another. Pretending you're not, is the real source of said subtle bugs. T -- Why waste time learning, when ignorance is instantaneous? -- Hobbes, from Calvin & Hobbes
Nov 20 2014
next sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"H. S. Teoh via Digitalmars-d"  wrote in message 
news:mailman.2156.1416499421.9932.digitalmars-d puremagic.com...

 By that logic, using an int to represent an integer is also using the
 incorrect type, because a signed type is *also* subject to module 2^^n
 arithmetic -- just a different form of it where the most negative value
 wraps around to the most positive values.  Fixed-width integers in
 computing are NOT the same thing as unrestricted integers in
 mathematics. No matter how you try to rationalize it, as long as you use
 hardware fix-width "integers", you're dealing with modulo arithmetic in
 one form or another. Pretending you're not, is the real source of said
 subtle bugs.
While what you've said is true, the typical range of values stored in an integral type is much more likely to cause unsigned wrapping than signed overflow. So to get the desired 'integer-like' behaviour from D's integral types, you need to care about magnitude for signed types, or both magnitude and ordering for unsigned types. eg 'a < b' becoming 'a - b < 0' is valid for integers, and small ints, but not valid for small uints unless a > b. You will always have to care about the imperfect representation of mathematical integers, but with unsigned types you have an extra rule that is much more likely to affect typical code.
Nov 21 2014
prev sibling parent "Kagamin" <spam here.lot> writes:
On Thursday, 20 November 2014 at 16:03:41 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 By that logic, using an int to represent an integer is also 
 using the
 incorrect type, because a signed type is *also* subject to 
 module 2^^n
 arithmetic -- just a different form of it where the most 
 negative value
 wraps around to the most positive values.
The type is chosen at design time so that it's unlikely to overflow for the particular scenario. Why would you want the count of objects to reset at some point when counting objects? Wrapping of unsigned integers has valid usage for e.g. hash functions, but there they are used as bit arrays, not proper numbers, and arithmetic operators are used for bit shuffling, not for computing some numbers.
Nov 21 2014
prev sibling next sibling parent "Steve Sobel" <s.sobellian gmail.com> writes:
On Thursday, 20 November 2014 at 08:18:24 UTC, Don wrote:
 ...

 It's particularly challenging in D because of the widespread 
 use of 'auto':

 auto x = foo();
 auto y = bar();
 auto z = baz();

 if (x - y > z) { ... }


 This might be a bug, if one of these functions returns an 
 unsigned type.  Good luck finding that. Note that if all 
 functions return unsigned, there isn't even any signed-unsigned 
 mismatch.

 ...
I personally think this code is bad style. If the function requires a signed integer type, then `auto` with no qualifications at all is clearly too loose- if the programmer had specified what he needed to begin with, the error would have been caught at compile time. You can replace `auto` with an explicit signed integer type like `long`. If foo and bar are template parameters and you don't know the precise return type, then a static assert that x and y are signed will do the trick. If it is known that x > y and the function does not require a signed integer type, then an assert should be used. Frankly that snippet just illustrates the sort of constraints that should be put on generic code.
Nov 20 2014
prev sibling parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Thu, 20 Nov 2014 08:18:23 +0000
schrieb "Don" <x nospam.com>:

 It's particularly challenging in D because of the widespread use=20
 of 'auto':
=20
 auto x =3D foo();
 auto y =3D bar();
 auto z =3D baz();
=20
 if (x - y > z) { ... }
=20
=20
 This might be a bug, if one of these functions returns an=20
 unsigned type.  Good luck finding that. Note that if all=20
 functions return unsigned, there isn't even any signed-unsigned=20
 mismatch.
With those function names I cannot write code. =E2=84=95 x =3D length(); =E2=84=95 y =3D index(); =E2=84=95 z =3D requiredRange(); if (x - y > z) { ... } Ah, now we're getting somewhere. Yes the code is obviously correct. You need to be aware of the value ranges of your variables and write subtractions in a way that the result can only be >=3D 0. If you realize that you cannot guarantee that for some case, you just found a logic bug. An invalid program state that you need to assert/if-else/throw. I don't get why so many APIs return ints. Must be to support Java or something where proper unsigned types aren't available. --=20 Marco
Nov 21 2014
parent reply "Don" <x nospam.com> writes:
On Friday, 21 November 2014 at 17:23:51 UTC, Marco Leise wrote:
 Am Thu, 20 Nov 2014 08:18:23 +0000
 schrieb "Don" <x nospam.com>:

 It's particularly challenging in D because of the widespread 
 use of 'auto':
 
 auto x = foo();
 auto y = bar();
 auto z = baz();
 
 if (x - y > z) { ... }
 
 
 This might be a bug, if one of these functions returns an 
 unsigned type.  Good luck finding that. Note that if all 
 functions return unsigned, there isn't even any 
 signed-unsigned mismatch.
With those function names I cannot write code. ℕ x = length(); ℕ y = index(); ℕ z = requiredRange(); if (x - y > z) { ... } Ah, now we're getting somewhere. Yes the code is obviously correct. You need to be aware of the value ranges of your variables and write subtractions in a way that the result can only be >= 0. If you realize that you cannot guarantee that for some case, you just found a logic bug. An invalid program state that you need to assert/if-else/throw.
Yup. And that is not captured in the type system.
 I don't get why so many APIs return ints. Must be to support
 Java or something where proper unsigned types aren't available.
???? D and C do not have suitable types either. unsigned != ℕ. In D, 1u - 2u > 0u. This is defined behaviour, not an overflow.
Nov 24 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/24/14 4:54 AM, Don wrote:
 In D,  1u - 2u > 0u. This is defined behaviour, not an overflow.
I think I get what you mean, but overflow is also defined behavior (in D at least). -- Andrei
Nov 24 2014
parent reply "Don" <x nospam.com> writes:
On Monday, 24 November 2014 at 15:56:44 UTC, Andrei Alexandrescu 
wrote:
 On 11/24/14 4:54 AM, Don wrote:
 In D,  1u - 2u > 0u. This is defined behaviour, not an 
 overflow.
I think I get what you mean, but overflow is also defined behavior (in D at least). -- Andrei
Aargh! You're right. That's new, and dreadful. It didn't used to be. The offending commit is alexrp 2012-05-15 15:37:24 which only provides an unsigned example. Why are defining behaviour that is always a bug? Java makes it defined, but it has to because it doesn't have unsigned types. I think the intention probably was to improve on the C situation, where there is undefined behaviour that really should be defined. But do we really want to preclude ever having overflow checking for integers?
Nov 25 2014
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Don:

 Aargh! You're right. That's new, and dreadful. It didn't used 
 to be.
 The offending commit is

 alexrp              2012-05-15 15:37:24

 which only provides an unsigned example.

 Why are defining behaviour that is always a bug? Java makes it 
 defined, but it has to because it doesn't have unsigned types.
 I think the intention probably was to improve on the C 
 situation, where there is undefined behaviour that really 
 should be defined.

 But do we really want to preclude ever having overflow checking 
 for integers?
+1 Bye, bearophile
Nov 25 2014
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Tuesday, 25 November 2014 at 11:43:01 UTC, Don wrote:
 Why are defining behaviour that is always a bug? Java makes it 
 defined, but it has to because it doesn't have unsigned types.
 I think the intention probably was to improve on the C 
 situation, where there is undefined behaviour that really 
 should be defined.
Mostly to prevent optimizations based on no-overflow assumption.
 But do we really want to preclude ever having overflow checking 
 for integers?
Overflow checking doesn't contradict to overflow being defined. The latter simply reflects how hardware works, nothing else. And hardware works that way, because that's a fast implementation of arithmetic for general case.
Nov 25 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 25 November 2014 at 13:52:32 UTC, Kagamin wrote:
 Overflow checking doesn't contradict to overflow being defined. 
 The latter simply reflects how hardware works, nothing else. 
 And hardware works that way, because that's a fast 
 implementation of arithmetic for general case.
So you are basically saying that D does not provide modular arithmetic, but allows you to continue with the incorrect result of an overflow as a modulo representation? Because you have to choose, you cannot both have modular arithmetic and overflow at the same time for the same operator. Overflow happens because you have monotonic semantics for addition, not modular semantics. Btw, http://dlang.org/expression needs a clean up, the term "underflow" is not used correctly.
Nov 25 2014
parent reply "Kagamin" <spam here.lot> writes:
On Tuesday, 25 November 2014 at 14:30:36 UTC, Ola Fosheim Grøstad 
wrote:
 So you are basically saying that D does not provide modular 
 arithmetic, but allows you to continue with the incorrect 
 result of an overflow as a modulo representation?
Correctness is an emergent property - when behavior matches expectation, so overflow has variable correctness in various parts of the code.
Nov 25 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 25 November 2014 at 15:42:13 UTC, Kagamin wrote:
 Correctness is an emergent property - when behavior matches 
 expectation, so overflow has variable correctness in various 
 parts of the code.
I assume you are basically saying that Walter's view that matching C++ is more important than getting it right, because some people might expect C++ behaviour. Yet Ada chose a different path and is considered a better language with respect to correctness. I think it is important to get the definitions consistent and sound so they are easy to reason about, both for users and implementors. So one should choose whether the type is primarily monotonic, with incorrect values "truncated into" modulo N, or if the type is primarily modular. If addition is defined to be primarily monotonic it means you can optimize "if(x < x+1)…" into "if (true)…". If it is defined to be primarily modular, then you cannot.
Nov 25 2014
parent reply "Kagamin" <spam here.lot> writes:
On Tuesday, 25 November 2014 at 15:52:22 UTC, Ola Fosheim Grøstad 
wrote:
 I assume you are basically saying that Walter's view that 
 matching C++ is more important than getting it right, because 
 some people might expect C++ behaviour. Yet Ada chose a 
 different path and is considered a better language with respect 
 to correctness.
C++ legacy is huge especially in culture. That said, the true issue is in beliefs (which probably stem from 16-bit era). Can't judge Ada, have no experience with it, though examples of Java and .net show how marginal is importance of unsigned types.
 I think it is important to get the definitions consistent and 
 sound so they are easy to reason about, both for users and 
 implementors. So one should choose whether the type is 
 primarily monotonic, with incorrect values "truncated into" 
 modulo N, or if the type is primarily modular.
In this light examples by Marco Leise become interesting, he tries to evade wrapping even for unsigned types, so, yes types are primarily monotonic and optimized for small values.
 If addition is defined to be primarily monotonic it means you 
 can optimize "if(x < x+1)…" into "if (true)…". If it is defined 
 to be primarily modular, then you cannot.
Such optimizations have a bad reputation. If they were more conservative and didn't propagate back in code flow, the situation would be probably better. Also isn't (x < x+1) a suspicious expression, is it a good idea to mess with it?
Nov 25 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 25 November 2014 at 18:24:29 UTC, Kagamin wrote:
 C++ legacy is huge especially in culture. That said, the true 
 issue is in beliefs (which probably stem from 16-bit era). 
 Can't judge Ada, have no experience with it, though examples of 
 Java and .net show how marginal is importance of unsigned types.
Unsigned bytes are important, and I personally tend to make just about everything unsigned when dealing with C-like languages because that makes me aware of the pitfalls and I avoid the signedness issue. The downside is that it takes extra work to get the evaluation order right and you have to take extra care to make sure loops terminate correctly by being very conscious about +-1 issues when terminating around zero. But I don't really think C++ legacy is a good reason to keep implicit coercion no matter what programming style one has. Coercion is generally something I try to avoid, even explicitly, so why would I want the compiler to do it with no warning?
 Such optimizations have a bad reputation. If they were more 
 conservative and didn't propagate back in code flow, the 
 situation would be probably better. Also isn't (x < x+1) a 
 suspicious expression, is it a good idea to mess with it?
It is just an example, it could be the result of substituting aliased values. Anyway, I think it is important to not only define what happens if you add 1 to 0xffffffff, but also define whether that result is considered in correspondence with the type. If it isn't a correct value for the type, then the programmer will have to make no assumptions that optimizations will heed the resulting incorrect value. The only acceptable alternative is to have the language specification explicitly define the type as modular and overflow free. If not you end up with weak typing…? I personally would take the monotonic optimizations and rather have a separate bit-fidling type that provides a clean builtin swiss-army-knife toolset that gives close to direct access to the whole arsenal that the CPU instruction set provides (carry, ROL/ROR, bitcounts etc).
Nov 25 2014
next sibling parent "Frank Like" <1150015857 qq.com> writes:
when I migrate dfl codes from x86 to 64 bit,modify the drawing.d 
,find the 'offset' and 'index',point(x,y),rect(x,y....),all be 
keep with the 'lengh's type, so I don't modify them to 
size_t,only cast(int)length to int,then it's easy to migrate dfl 
codes to 64 bit.
Ok,then dfl can work  on 64 bit now.
Nov 26 2014
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Tuesday, 25 November 2014 at 22:56:50 UTC, Ola Fosheim Grøstad 
wrote:
 I personally would take the monotonic optimizations and rather 
 have a separate bit-fidling type that provides a clean builtin 
 swiss-army-knife toolset that gives close to direct access to 
 the whole arsenal that the CPU instruction set provides (carry, 
 ROL/ROR, bitcounts etc).
I don't think there's such clear separation that can be expressed in a type, it's more in used coding practices rather than type. You can't change coding practice by introducing a new type.
Nov 27 2014
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 27 November 2014 at 08:31:24 UTC, Kagamin wrote:
 I don't think there's such clear separation that can be 
 expressed in a type, it's more in used coding practices rather 
 than type. You can't change coding practice by introducing a 
 new type.
You need to separate and define the old types as well as introducing a clean way to do low level manipulation. How to do the latter is not as clear, but… …regular types should be constrained to convey the intent of the programmer. The intent is conveyed to the compiler and to readers of the source-code. So the type definition should be strict on whether the intent is to convey monotonic qualities or circular/modular qualities. The C-practice of casting from void* to char* to float to uint to int in order to do bit manipulation leads to badly structured code. Intrinsics also leads to less readable code. There's got to be a better solution to keep "bit hacks" separate from regular code. Maybe a register type that maps onto SIMD registers…
Nov 27 2014
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Kagamin:

 You can't change coding practice by introducing a new type.
We can try to change coding practice introducing new types :-) Bye, bearophile
Nov 27 2014
prev sibling next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 24 Nov 2014 12:54:58 +0000
Don via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 In D,  1u - 2u > 0u. This is defined behaviour, not an overflow.
this *is* overflow. D just has overflow result defined.
Nov 24 2014
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 24 November 2014 at 16:00:53 UTC, ketmar via 
Digitalmars-d wrote:
 this *is* overflow. D just has overflow result defined.
So it basically is and isn't modular arithmetic at the same time? I think Ada got this right by providing the ability to specify the modulo value, so you can define: type Weekday is mod 7; type Byte is mod 256; A solid solution solution is to provide «As if Infinitely Ranged Integer Model» where the compiler figures out how large integers are needed for computation and then does overflow detection when you truncate for storage: http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=9019
Nov 24 2014
parent reply "Matthias Bentrup" <matthias.bentrup googlemail.com> writes:
On Monday, 24 November 2014 at 16:45:35 UTC, Ola Fosheim Grøstad
wrote:
 On Monday, 24 November 2014 at 16:00:53 UTC, ketmar via 
 Digitalmars-d wrote:
 this *is* overflow. D just has overflow result defined.
So it basically is and isn't modular arithmetic at the same time?
Overflow is part of modular arithmetic. However, there is no signed and unsigned modular arithmetic, or, more precisely, they are the same. Computer words just aren't a good representation of integers. You can either use modular arithmetic, which follows the common arithmetic laws for addition and multiplication (commutativity, associativity, etc., even most non-zero numbers have a multiplicative inverse), but break the common ordering laws (a >= 0 && b >= 0 implies a+b >= 0). Or you can use some other order preserving arithmetic (e.g. saturating to min/max values), but that breaks the arithmetic laws.
 I think Ada got this right by providing the ability to specify 
 the modulo value, so you can define:

 type Weekday is mod 7;
 type Byte is mod 256;

 A solid solution solution is to provide «As if Infinitely 
 Ranged Integer Model» where the compiler figures out how large 
 integers are needed for computation and then does overflow 
 detection when you truncate for storage:

 http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=9019
You could just as well use a library like GMP.
Nov 24 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 24 November 2014 at 17:12:31 UTC, Matthias Bentrup 
wrote:
 Overflow is part of modular arithmetic. However, there is no
 signed and unsigned modular arithmetic, or, more precisely, they
 are the same.
Would you say that a phase that goes from 0…2pi overflows? Does polar coordinates overflow once every turn? I'd say overflow/underflow means that the result is wrong. (Carry is not overflow per se).
 Or you can use some other order preserving arithmetic (e.g.
 saturating to min/max values), but that breaks the arithmetic
 laws.
I don't think it breaks them, but I think a system language would be better off by having explicit operators for alternative edge-case handling on a bit-fiddling type. E.g.: a + b as regular addition a (+) b as modulo arithmetic addition a [+] b as clamped (saturating) addition The bad behaviour of C-like languages is the implicit coercion to/from a bit-fiddling type. The bit-fiddling should be contained in expression where the programmer by choosing the type says "I am gonna do tricky bit hacks here". Just casting to uint does not convey that message in a clear manner.
 A solid solution solution is to provide «As if Infinitely 
 Ranged Integer Model» where the compiler figures out how large 
 integers are needed for computation and then does overflow 
 detection when you truncate for storage:

 http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=9019
You could just as well use a library like GMP.
I think the point with having compiler support is to retain most optimizations. The compiler select the most efficient representation based on the needed headroom and makes sure that overflow is recorded so that you can eventually respond to it. If you couple AIR with constrained integer types, which Pascal and Ada has, then it can be very efficient in many cases.
Nov 24 2014
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 24 November 2014 at 17:55:06 UTC, Ola Fosheim Grøstad 
wrote:
 I think the point with having compiler support is to retain 
 most optimizations. The compiler select the most efficient 
 representation based on the needed headroom and makes sure that 
 overflow is recorded so that you can eventually respond to it.
It is also worth noting that Intel CPUs have 3 new instructions for working with large integers: MULX and ADCX/ADOX. http://www.intel.com/content/www/us/en/intelligent-systems/intel-technology/ia-large-integer-arithmetic-paper.html So there is no reason to not go for it IMO.
Nov 24 2014
prev sibling parent reply "Matthias Bentrup" <matthias.bentrup googlemail.com> writes:
On Monday, 24 November 2014 at 17:55:06 UTC, Ola Fosheim Grøstad
wrote:
 On Monday, 24 November 2014 at 17:12:31 UTC, Matthias Bentrup 
 wrote:
 Overflow is part of modular arithmetic. However, there is no
 signed and unsigned modular arithmetic, or, more precisely, 
 they
 are the same.
Would you say that a phase that goes from 0…2pi overflows? Does polar coordinates overflow once every turn?
No, sin and cos are periodic functions, but that doesn't mean their arguments are modular. sin 4pi is well defined by e.g. the taylor expansion of sin without any modular arithmetic at all.
 I'd say overflow/underflow means that the result is wrong. 
 (Carry is not overflow per se).
There is no right or wrong in Mathematics, only true and false. The result of modular addition with overflow is not wrong, it is just different than the result of integer addition.
 Or you can use some other order preserving arithmetic (e.g.
 saturating to min/max values), but that breaks the arithmetic
 laws.
I don't think it breaks them, but I think a system language would be better off by having explicit operators for alternative edge-case handling on a bit-fiddling type. E.g.: a + b as regular addition a (+) b as modulo arithmetic addition a [+] b as clamped (saturating) addition The bad behaviour of C-like languages is the implicit coercion to/from a bit-fiddling type. The bit-fiddling should be contained in expression where the programmer by choosing the type says "I am gonna do tricky bit hacks here". Just casting to uint does not convey that message in a clear manner.
Agreed, though I don't like the explosion of new operators. I'd prefer the C# syntax like check(<expression>), wrap(expression), saturate(expression).
 A solid solution solution is to provide «As if Infinitely 
 Ranged Integer Model» where the compiler figures out how 
 large integers are needed for computation and then does 
 overflow detection when you truncate for storage:

 http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=9019
You could just as well use a library like GMP.
I think the point with having compiler support is to retain most optimizations. The compiler select the most efficient representation based on the needed headroom and makes sure that overflow is recorded so that you can eventually respond to it. If you couple AIR with constrained integer types, which Pascal and Ada has, then it can be very efficient in many cases.
And can fail spectacularly in others. The compiler always has to prepare for the worst case, i.e. the largest integer size possible, while in practice you may need that only for a few extreme cases.
Nov 24 2014
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 24 November 2014 at 19:06:35 UTC, Matthias Bentrup 
wrote:
 There is no right or wrong in Mathematics, only true and false.
 The result of modular addition with overflow is not wrong, it is
 just different than the result of integer addition.
I think we are talking past each other. In my view the term "overflow" has nothing to do with mathematics, overflow is a signal from the ALU that the computation is incorrect e.g. not in accordance with the intended type.
 Agreed, though I don't like the explosion of new operators. I'd
 prefer the C# syntax like check(<expression>), wrap(expression),
 saturate(expression).
Yep, that is another way to do it. What is preferable probably varies from case to case.
 And can fail spectacularly in others. The compiler always has to
 prepare for the worst case, i.e. the largest integer size
 possible, while in practice you may need that only for a few
 extreme cases.
In some loops it probably can get tricky to get it right without help from the programmer. I believe some languages allow you to annotate loops with an upper boundary to help the semantic analysis, but you could also add more frequent overflow checks on request?
Nov 24 2014
prev sibling parent "FrankLike" <1150015857 qq.com> writes:
On Monday, 24 November 2014 at 19:06:35 UTC, Matthias Bentrup 
wrote:
 Agreed, though I don't like the explosion of new operators. I'd
 prefer the C# syntax like check(<expression>), wrap(expression),
 saturate(expression).
You maybe like this: -------------------small test 1-------------------------- import std.stdio; template subuint(T1,T2){ auto subuint(T1 x, T2 y, ref bool overflow) { if(is(T1 == uint) && is(T2==uint)) { if (x < y) { return cast(int)(x -y); } else { return x - y; } } else if(is(T1 == uint) && is(T2==int)) {writeln("enter here1"); if (x < y) { writeln("enter here2"); return cast(int)(x -y); } else { writeln("enter here3"); return x - y; } } else if(is(T1 == int) && is(T2==uint)) { if (x < y) { return cast(int)(x -y); } else { return x - y; } } else if(is(T1 == int) && is(T2==int)) { return x - y; } } } unittest { bool overflow; assert(subuint(3, 2, overflow) == 1); assert(!overflow); assert(subuint(3, 4, overflow) == -1); assert(!overflow); assert(subuint(uint.max, 1, overflow) == uint.max - 1); writeln("typeid = ",typeid(subuint(uint.max, 1, overflow))); assert(!overflow); assert(subuint(1, 1, overflow) == uint.min); assert(!overflow); assert(subuint(0, 1, overflow) == -1); assert(!overflow); assert(subuint(uint.max - 1, uint.max, overflow) == -1); assert(!overflow); assert(subuint(0, 0, overflow) == 0); assert(!overflow); assert(subuint(3, -2, overflow) == 5); assert(!overflow); assert(subuint(uint.max, -1, overflow) == uint.max + 1); assert(!overflow); assert(subuint(1, -1, overflow) == 2); assert(!overflow); assert(subuint(0, -1, overflow) == 1); assert(!overflow); assert(subuint(uint.max - 1, int.max, overflow) == int.max); assert(!overflow); assert(subuint(0, 0, overflow) == 0); assert(!overflow); assert(subuint(-2, 1, overflow) == -3); assert(!overflow); } void main() { uint a= 3; int b = 4; int c =2; writeln("c -a =",c-a); writeln("a -b =",a-b); writeln("----------------"); bool overflow; writeln("typeid = ",typeid(subuint(a, b, overflow)),", a-b=",subuint(a, b, overflow)); writeln("ok"); } ---------------here is a simple ,but it's error-------------------------- import std.stdio; template subuint(T1,T2){ auto subuint(T1 x, T2 y, ref bool overflow) { if(is(T1 == int) && is(T2==int)) { return x - y; } else if((is(T1 == uint) && is(T2==int)) | (is(T1 == uint) && is(T2==uint)) | (is(T1 == int) && is(T2==uint))) { if (x < y) { return cast(int)(x -y); } else { return x - y; } } } } void main() { uint a= 3; int b = 4; int c =2; writeln("c -a =",c-a); writeln("a -b =",a-b); writeln("----------------"); bool overflow; writeln("typeid = ",typeid(subuint(a, b, overflow)),", a-b=",subuint(a, b, overflow)); writeln("ok"); }
Nov 24 2014
prev sibling parent reply "Don" <x nospam.com> writes:
On Monday, 24 November 2014 at 16:00:53 UTC, ketmar via 
Digitalmars-d wrote:
 On Mon, 24 Nov 2014 12:54:58 +0000
 Don via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 In D,  1u - 2u > 0u. This is defined behaviour, not an 
 overflow.
this *is* overflow. D just has overflow result defined.
No, that is not overflow. That is a carry. Overflow is when the sign bit changes.
Nov 24 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 25 November 2014 at 07:39:44 UTC, Don wrote:
 No, that is not overflow. That is a carry. Overflow is when the 
 sign bit changes.
I think this discussion will be less confusing with clearing up the terminology. An overflow condition happens when the representation cannot hold the magnitude of the intended type. In floating point that is +Inf and -Inf. And underflow condition happens when the representation cannot represent the precision of small numbers. In floating point that is +0, -0 and denormal numbers, detected or undetected. Carry is an extra bit that can be considered part of the computation for a concrete machine code instruction that provides carry. Eg 32bits + 32bits => (32+1) bits. If the intended type is true Reals and the representation is integer then we get: 0u - 1u => overflow 1u / 2u => underflow Carry can be taken as an overflow condition, but it is not proper overflow if you interpret it as s part of the result that depends on the machine language instruction and use of it. For a regular ADD/SUB instruction with carry the ALU covers two intended types (signed/unsigned) and use the control register flags in a way which let's the programmer make the interpretation. Some SIMD instructions does not provide control register flags and are therefore true modular arithmetic that does not overflow by definition, but if you use them for representing a non-modular intended type then you get undetected overflow… Overflow is in relation to an interpretation: the intended type versus the internal representation and the concrete machine language instruction.
Nov 25 2014
prev sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Mon, 24 Nov 2014 12:54:58 +0000
Don via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 In D,  1u - 2u > 0u. This is defined behaviour, not an overflow.
p.s. sorry, of course this is not and overflow. this is underflow.
Nov 24 2014
prev sibling next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 19 Nov 2014 10:03:34 +0000
Don via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 No! No! No!  This is completely wrong. Unsigned does not mean=20
 "positive". It means "no sign", and therefore "wrapping=20
 semantics".
 eg length - 4 > 0, if length is 2.
=20
 Weird consequence: using subtraction with an unsigned type is=20
 nearly always a bug.
negative length is a bug too. and it doesn't matter what king of integer is used if you didn't fail your sanity checks.
 I wish D hadn't called unsigned integers 'uint'. They should have=20
 been called '__uint' or something. They should look ugly. You=20
 need a very, very good reason to use an unsigned type.
=20
 We have a builtin type that is deadly but seductive.
you just named all of built-in types. ah, and rename all keywords too, they far too dangerous.
Nov 19 2014
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 11/19/14, 10:21 AM, ketmar via Digitalmars-d wrote:
 On Wed, 19 Nov 2014 10:03:34 +0000
 Don via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 No! No! No!  This is completely wrong. Unsigned does not mean
 "positive". It means "no sign", and therefore "wrapping
 semantics".
 eg length - 4 > 0, if length is 2.

 Weird consequence: using subtraction with an unsigned type is
 nearly always a bug.
negative length is a bug too.
How is that a bug? Can you provide some code that exhibits this?
Nov 19 2014
parent reply "FrankLike" <1150015857 qq.com> writes:
 How is that a bug? Can you provide some code that exhibits this?
If you compile the dfl Library to 64 bit,you will find error: core.sys.windows.windows.WaitForMultipleObjects(uint nCount,void** lpHandles,....) is not callable using argument types(ulong,void**,...) the 'WaitForMultipleObjects' Function is in dmd2/src/druntime/src/core/sys/windows/windows.d the argument of first is dfl's value ,it comes from a 'length' ,it's type is size_t,now it is 'ulong' on 64 bit. So druntime must keep the same as phobos for size_t. Or keep the same to int with WindowsAPI to modify the size_t to int ?
Nov 19 2014
next sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
On 11/19/14, 9:54 PM, FrankLike wrote:
 How is that a bug? Can you provide some code that exhibits this?
If you compile the dfl Library to 64 bit,you will find error: core.sys.windows.windows.WaitForMultipleObjects(uint nCount,void** lpHandles,....) is not callable using argument types(ulong,void**,...) the 'WaitForMultipleObjects' Function is in dmd2/src/druntime/src/core/sys/windows/windows.d the argument of first is dfl's value ,it comes from a 'length' ,it's type is size_t,now it is 'ulong' on 64 bit. So druntime must keep the same as phobos for size_t. Or keep the same to int with WindowsAPI to modify the size_t to int ?
Sorry, maybe I wasn't clear. I asked "how a negative length can be a bug". (because you can't set a negative length, so it can't really happen)
Nov 19 2014
prev sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"FrankLike"  wrote in message news:musbvhmuuhhvetovxqwb forum.dlang.org...

 If you compile the dfl Library to 64 bit,you will find error:

 core.sys.windows.windows.WaitForMultipleObjects(uint
 nCount,void** lpHandles,....) is not callable using argument
 types(ulong,void**,...)

 the 'WaitForMultipleObjects' Function is in
 dmd2/src/druntime/src/core/sys/windows/windows.d

 the argument of first is dfl's value ,it comes from a 'length'
 ,it's type is size_t,now it is 'ulong' on 64 bit.

 So druntime must keep the same as  phobos for size_t.
 Or  keep the same to int with WindowsAPI to  modify the size_t to int ?
I suggest using WaitForMultipleObjects(to!uint(xxx.length), ...) as it will both convert and check for overflow IIRC. I'm just happy D gives you an error here instead of silently truncating the value.
Nov 21 2014
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/19/14 2:03 AM, Don wrote:
 On Tuesday, 18 November 2014 at 18:23:52 UTC, Marco Leise wrote:
 Am Tue, 18 Nov 2014 15:01:25 +0000
 schrieb "Frank Like" <1150015857 qq.com>:

 but now ,'int' is enough for use,not huge and not small,only > enough.
 'int' is easy to write,and most people are used to it.
 Most importantly easier to migrate code,if  'length''s return
value type is 'int'.
How about your idea?
I get the idea of a broken record right now... Clearly size_t (which I tend to alias with ℕ in my code for brevity and coolness) can express more than 2^31-1 items, which is appropriate to reflect the increase in usable memory per application on 64-bit platforms. Yes, the 64-bit version of a program or library can handle larger data sets. Just like it was when people transitioned from 16-bit to 32-bit. I wont use `int` just because the technically correct thing is `size_t`, even it it is a little harder to type.
This is difficult. Having arr.length return an unsigned type, is a dreadful language mistake.
 Aside from the size factor, I personally prefer unsigned types
 for countable stuff like array lengths. Mixed arithmetics
 decay to unsinged anyways and you don't need checks like
 `assert(idx >= 0)`. It is a matter of taste though and others
 prefer languages with no unsigned types at all.
No! No! No! This is completely wrong. Unsigned does not mean "positive". It means "no sign", and therefore "wrapping semantics". eg length - 4 > 0, if length is 2. Weird consequence: using subtraction with an unsigned type is nearly always a bug. I wish D hadn't called unsigned integers 'uint'. They should have been called '__uint' or something. They should look ugly. You need a very, very good reason to use an unsigned type. We have a builtin type that is deadly but seductive.
I agree this applies to C and C++. Not quite to D. -- Andrei
Nov 19 2014
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 11/19/14, 1:46 PM, Andrei Alexandrescu wrote:
 On 11/19/14 2:03 AM, Don wrote:
 We have a builtin type that is deadly but seductive.
I agree this applies to C and C++. Not quite to D. -- Andrei
See my response to Don. Don't you think that's counter-intuitive?
Nov 19 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/19/14 10:13 AM, Ary Borenszweig wrote:
 On 11/19/14, 1:46 PM, Andrei Alexandrescu wrote:
 On 11/19/14 2:03 AM, Don wrote:
 We have a builtin type that is deadly but seductive.
I agree this applies to C and C++. Not quite to D. -- Andrei
See my response to Don. Don't you think that's counter-intuitive?
No. -- Andrei
Nov 19 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 No. -- Andrei
Yet, experience in D has shown very well that having unsigned lengths is the wrong design choice. It's a D wart. Bye, bearophile
Nov 19 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/19/14 12:38 PM, bearophile wrote:
 Andrei Alexandrescu:

 No. -- Andrei
Yet, experience in D has shown very well that having unsigned lengths is the wrong design choice. It's a D wart.
Care to back that up? -- Andrei
Nov 19 2014
parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 20 November 2014 at 00:07:23 UTC, Andrei 
Alexandrescu wrote:
 On 11/19/14 12:38 PM, bearophile wrote:
 Andrei Alexandrescu:

 No. -- Andrei
Yet, experience in D has shown very well that having unsigned lengths is the wrong design choice. It's a D wart.
Care to back that up? -- Andrei
Don mentioned troubles with that at DConf.
Nov 19 2014
prev sibling parent reply "flamencofantasy" <flamencofantasy gmail.com> writes:
On Wednesday, 19 November 2014 at 20:38:15 UTC, bearophile wrote:
 Andrei Alexandrescu:

 No. -- Andrei
Yet, experience in D has shown very well that having unsigned lengths is the wrong design choice. It's a D wart. Bye, bearophile
Yet, MY experience in D has shown very well that having unsigned lengths is the RIGHT design choice. It's NOT a D wart.
Nov 19 2014
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Nov 20, 2014 at 01:00:00AM +0000, flamencofantasy via Digitalmars-d
wrote:
 On Wednesday, 19 November 2014 at 20:38:15 UTC, bearophile wrote:
[...]
Yet, experience in D has shown very well that having unsigned lengths
is the wrong design choice. It's a D wart.

Bye,
bearophile
Yet, MY experience in D has shown very well that having unsigned lengths is the RIGHT design choice. It's NOT a D wart.
[...] I concur. However, the fact that you can freely mix signed and unsigned types in unsafe ways without any warning, is a fly that spoils the soup. If this kind of unsafe mixing wasn't allowed, or required explict casts (to signify "yes I know what I'm doing and I'm prepared to face the consequences"), I suspect that bearophile would be much happier about this issue. ;-) T -- MAS = Mana Ada Sistem?
Nov 19 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/19/2014 5:03 PM, H. S. Teoh via Digitalmars-d wrote:
 If this kind of unsafe mixing wasn't allowed, or required explict casts
 (to signify "yes I know what I'm doing and I'm prepared to face the
 consequences"), I suspect that bearophile would be much happier about
 this issue. ;-)
Explicit casts are worse than the problem - they can easily cause bugs. As for me personally, I like having a complete set of signed and unsigned integral types at my disposal. It's like having a full set of wrenches that are open end on one end and boxed on the other :-) Most of the time either end will work, but sometimes only one will. Now, if D were a non-systems language like Basic, Go or Java, unsigned types could be reasonably dispensed with. But D is a systems programming language, and it ought to have available types that match what the hardware supports.
Nov 20 2014
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 11/20/14, 5:02 AM, Walter Bright wrote:
 On 11/19/2014 5:03 PM, H. S. Teoh via Digitalmars-d wrote:
 If this kind of unsafe mixing wasn't allowed, or required explict casts
 (to signify "yes I know what I'm doing and I'm prepared to face the
 consequences"), I suspect that bearophile would be much happier about
 this issue. ;-)
Explicit casts are worse than the problem - they can easily cause bugs. As for me personally, I like having a complete set of signed and unsigned integral types at my disposal. It's like having a full set of wrenches that are open end on one end and boxed on the other :-) Most of the time either end will work, but sometimes only one will. Now, if D were a non-systems language like Basic, Go or Java, unsigned types could be reasonably dispensed with. But D is a systems programming language, and it ought to have available types that match what the hardware supports.
Nobody is saying to remove unsigned types from the language. They have their uses. It's just that using them for an array's length leads to subtle bugs. That's all.
Nov 20 2014
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Nov 20, 2014 at 11:22:00AM -0300, Ary Borenszweig via Digitalmars-d
wrote:
 On 11/20/14, 5:02 AM, Walter Bright wrote:
[...]
As for me personally, I like having a complete set of signed and
unsigned integral types at my disposal. It's like having a full set
of wrenches that are open end on one end and boxed on the other :-)
Most of the time either end will work, but sometimes only one will.

Now, if D were a non-systems language like Basic, Go or Java,
unsigned types could be reasonably dispensed with. But D is a systems
programming language, and it ought to have available types that match
what the hardware supports.
Nobody is saying to remove unsigned types from the language. They have their uses. It's just that using them for an array's length leads to subtle bugs. That's all.
Using unsigned types for array length doesn't necessarily lead to subtle bugs, if the language was stricter about mixing signed and unsigned values. T -- Recently, our IT department hired a bug-fix engineer. He used to work for Volkswagen.
Nov 20 2014
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 20 November 2014 at 15:55:21 UTC, H. S. Teoh via
Digitalmars-d wrote:
 Using unsigned types for array length doesn't necessarily lead 
 to subtle
 bugs, if the language was stricter about mixing signed and 
 unsigned
 values.
Yes, I think that this is the real issue.
Nov 20 2014
parent reply "Wyatt" <wyatt.epp gmail.com> writes:
On Thursday, 20 November 2014 at 20:17:15 UTC, deadalnix wrote:
 On Thursday, 20 November 2014 at 15:55:21 UTC, H. S. Teoh via
 Digitalmars-d wrote:
 Using unsigned types for array length doesn't necessarily lead 
 to subtle
 bugs, if the language was stricter about mixing signed and 
 unsigned
 values.
Yes, I think that this is the real issue.
Thirded. Array lengths are always non-negative integers. This is axiomatic. But the subtraction thing keeps coming up in this thread; what to do? There's probably something fundamentally wrong with this and I'll probably be called an idiot by both "sides", but my gut feeling is that if expressions with subtraction simply returned a signed type by default, much of the problem would disappear. It doesn't catch everything and stuff like: uint x = 2; uint y = 4; uint z = x - y; ...is still going to overflow, but maybe you know what you're doing? More importantly, changing it to auto z = x - y; actually works as expected for the majority of cases. (I'm actually on the fence re: pass/warn/error on mixing, but I _will_ note C's promotion rules have bitten me in the ass a few times and I have no particular love for them.) -Wyatt PS: I can't even believe how this thread has blown up, considering how it started.
Nov 21 2014
parent Marco Leise <Marco.Leise gmx.de> writes:
Am Fri, 21 Nov 2014 16:32:20 +0000
schrieb "Wyatt" <wyatt.epp gmail.com>:

 Array lengths are always non-negative integers.  This is=20
 axiomatic.  But the subtraction thing keeps coming up in this=20
 thread; what to do?
=20
 There's probably something fundamentally wrong with this and I'll=20
 probably be called an idiot by both "sides", but my gut feeling=20
 is that if expressions with subtraction simply returned a signed=20
 type by default, much of the problem would disappear. [...]
As I said above, I always order my unsigned variables by magnitude and uint.max - uint.min should result in uint.max and not -1. In code dealing with lengths or offsets there is typically some "base" that is less than the "position" or an "index" that is less than the "length". The expression `base - position` is just wrong. If it is in fact below "base" then you will end up with an if-else later on under guarantee. So why not place it up front: if (position >=3D base) { auto offset =3D position - base; } else { =E2=80=A6 }
 [...]
=20
 -Wyatt
=20
 PS: I can't even believe how this thread has blown up,=20
 considering how it started.
Exactly my thought, but suddenly I couldn't stop myself from posting. --=20 Marco
Nov 21 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/20/2014 6:22 AM, Ary Borenszweig wrote:
 Nobody is saying to remove unsigned types from the language. They have their
 uses. It's just that using them for an array's length leads to subtle bugs.
 That's all.
If that is changed to a signed type, then you'll have a same-only-different set of subtle bugs, plus you'll break the intuition about these things from everyone who has used C/C++ a lot.
Nov 20 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 If that is changed to a signed type, then you'll have a 
 same-only-different set of subtle bugs,
This is possible. Can you show some of the bugs, we can discuss them, and see if they are actually worse than the current situation. Bye, bearophile
Nov 20 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/20/2014 3:25 PM, bearophile wrote:
 Walter Bright:

 If that is changed to a signed type, then you'll have a same-only-different
 set of subtle bugs,
This is possible. Can you show some of the bugs, we can discuss them, and see if they are actually worse than the current situation.
All you're doing is trading 0 crossing for 0x7FFFFFFF crossing issues, and pretending the problems have gone away.
Nov 20 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/20/2014 7:11 PM, Walter Bright wrote:
 On 11/20/2014 3:25 PM, bearophile wrote:
 Walter Bright:

 If that is changed to a signed type, then you'll have a same-only-different
 set of subtle bugs,
This is possible. Can you show some of the bugs, we can discuss them, and see if they are actually worse than the current situation.
All you're doing is trading 0 crossing for 0x7FFFFFFF crossing issues, and pretending the problems have gone away.
BTW, granted the 0x7FFFFFFF problems exhibit the bugs less often, but paradoxically this can make the bug worse, because then it only gets found much, much later in supposedly tested & robust code. 0 crossing bugs tend to show up much sooner, and often immediately.
Nov 20 2014
next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 21 November 2014 at 04:53:38 UTC, Walter Bright wrote:
 BTW, granted the 0x7FFFFFFF problems exhibit the bugs less 
 often, but paradoxically this can make the bug worse, because 
 then it only gets found much, much later in supposedly tested & 
 robust code.

 0 crossing bugs tend to show up much sooner, and often 
 immediately.
Yes, I have to say the current design has some issue, but alternative seems worse.
Nov 20 2014
prev sibling next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Walter Bright"  wrote in message news:m4mggi$e1h$1 digitalmars.com...

 BTW, granted the 0x7FFFFFFF problems exhibit the bugs less often, but 
 paradoxically this can make the bug worse, because then it only gets found
 much, much later in supposedly tested & robust code.

 0 crossing bugs tend to show up much sooner, and often immediately.
I don't think I have ever written a D program where an array had more than 2^^31 elements. And I'm sure I've never had it where 2^31-1 wasn't enough and yet 2^^32-1 was. Zero, on the other hand, is usually quite near the typical array lengths and differences in lengths.
Nov 21 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/21/2014 12:10 AM, Daniel Murphy wrote:
 "Walter Bright"  wrote in message news:m4mggi$e1h$1 digitalmars.com...

 BTW, granted the 0x7FFFFFFF problems exhibit the bugs less often, but
 paradoxically this can make the bug worse, because then it only gets found
 much, much later in supposedly tested & robust code.

 0 crossing bugs tend to show up much sooner, and often immediately.
I don't think I have ever written a D program where an array had more than 2^^31 elements. And I'm sure I've never had it where 2^31-1 wasn't enough and yet 2^^32-1 was.
There turned out to be such a bug in one of the examples in "Programming Pearls" that remained undetected for many years: http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html
 Zero, on the other hand, is usually quite near the typical array lengths and
 differences in lengths.
That's true, that's why they are detected sooner, when it is less costly to fix them.
Nov 21 2014
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Walter Bright"  wrote in message news:m4mu0q$sc5$1 digitalmars.com...

 Zero, on the other hand, is usually quite near the typical array lengths 
 and
 differences in lengths.
That's true, that's why they are detected sooner, when it is less costly to fix them.
It would be even less costly if they weren't possible.
Nov 21 2014
parent reply "Matthias Bentrup" <matthias.bentrup googlemail.com> writes:
On Friday, 21 November 2014 at 08:54:40 UTC, Daniel Murphy wrote:
 "Walter Bright"  wrote in message 
 news:m4mu0q$sc5$1 digitalmars.com...

 Zero, on the other hand, is usually quite near the typical 
 array lengths and
 differences in lengths.
That's true, that's why they are detected sooner, when it is less costly to fix them.
It would be even less costly if they weren't possible.
C# has the checked and unchecked operators (http://msdn.microsoft.com/en-us/library/khy08726.aspx), which allow the programmer to specify if overflows should wrap of fail within an arithmetic expression. That could be a useful addition to D. However, a language that doesn't have unsigned integers and modular arithmetic is IMHO not a system language, because that is how most hardware works internally.
Nov 21 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/21/2014 1:01 AM, Matthias Bentrup wrote:
 C# has the checked and unchecked operators
 (http://msdn.microsoft.com/en-us/library/khy08726.aspx), which allow the
 programmer to specify if overflows should wrap of fail within an arithmetic
 expression. That could be a useful addition to D.
D already has them: https://github.com/D-Programming-Language/druntime/blob/master/src/core/checkedint.d
Nov 21 2014
parent "FrankLike" <1150015857 qq.com> writes:
 D already has them:

 https://github.com/D-Programming-Language/druntime/blob/master/src/core/checkedint.d
Druntime's checkint.d should be modify: uint subu(uint x, uint y, ref bool overflow) { if (x < y) return y - x; else return x - y; } ulong subu(ulong x, ulong y, ref bool overflow) { if (x < y) return y - x; else return x - y; } Frank
Nov 21 2014
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Friday, 21 November 2014 at 04:53:38 UTC, Walter Bright wrote:
 BTW, granted the 0x7FFFFFFF problems exhibit the bugs less 
 often, but paradoxically this can make the bug worse, because 
 then it only gets found much, much later in supposedly tested & 
 robust code.

 0 crossing bugs tend to show up much sooner, and often 
 immediately.
Wrong. Unsigned integers can hold bigger values, so it takes more to makes them overflow, hence the bug is harder to detect.
 http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html
 Specifically, it fails if the sum of low and high is greater 
 than the maximum positive int value
So it fails sooner for signed integers than for unsigned integers.
Nov 21 2014
prev sibling next sibling parent reply "Don" <x nospam.com> writes:
On Friday, 21 November 2014 at 04:53:38 UTC, Walter Bright wrote:
 On 11/20/2014 7:11 PM, Walter Bright wrote:
 On 11/20/2014 3:25 PM, bearophile wrote:
 Walter Bright:

 If that is changed to a signed type, then you'll have a 
 same-only-different
 set of subtle bugs,
This is possible. Can you show some of the bugs, we can discuss them, and see if they are actually worse than the current situation.
All you're doing is trading 0 crossing for 0x7FFFFFFF crossing issues, and pretending the problems have gone away.
BTW, granted the 0x7FFFFFFF problems exhibit the bugs less often, but paradoxically this can make the bug worse, because then it only gets found much, much later in supposedly tested & robust code. 0 crossing bugs tend to show up much sooner, and often immediately.
You're missing the point here. The problem is that people are using 'uint' as if it were a positive integer type. Suppose D had a type 'natint', which could hold natural numbers in the range 0..uint.max. Sounds like 'uint', right? People make the mistake of thinking that is what uint is. But it is not. How would natint behave, in the type system? typeof (natint - natint) == int NOT natint !!! This would of course overflow if the result is too big to fit in an int. But the type would be correct. 1 - 2 == -1. But typeof (uint - uint ) == uint. The bit pattern is identical to the other case. But the type is wrong. It is for this reason that uint is not appropriate as a model for positive integers. Having warnings about mixing int and uint operations in relational operators is a bit misleading, because mixing signed and unsigned is not usually the real problem. Instead, those warnings a symptom of a type system mistake. You are quite right in saying that with a signed length, overflows can still occur. But, those are in principle detectable. The compiler could add runtime overflow checks for them, for example. But the situation for unsigned is not fixable, because it is a problem with the type system. By making .length unsigned, we are telling people that if .length is used in a subtraction expression, the type will be wrong. It is the incorrect use of the type system that is the underlying problem.
Nov 21 2014
next sibling parent "Matthias Bentrup" <matthias.bentrup googlemail.com> writes:
On Friday, 21 November 2014 at 15:36:02 UTC, Don wrote:
 On Friday, 21 November 2014 at 04:53:38 UTC, Walter Bright 
 wrote:
 On 11/20/2014 7:11 PM, Walter Bright wrote:
 On 11/20/2014 3:25 PM, bearophile wrote:
 Walter Bright:

 If that is changed to a signed type, then you'll have a 
 same-only-different
 set of subtle bugs,
This is possible. Can you show some of the bugs, we can discuss them, and see if they are actually worse than the current situation.
All you're doing is trading 0 crossing for 0x7FFFFFFF crossing issues, and pretending the problems have gone away.
BTW, granted the 0x7FFFFFFF problems exhibit the bugs less often, but paradoxically this can make the bug worse, because then it only gets found much, much later in supposedly tested & robust code. 0 crossing bugs tend to show up much sooner, and often immediately.
You're missing the point here. The problem is that people are using 'uint' as if it were a positive integer type. Suppose D had a type 'natint', which could hold natural numbers in the range 0..uint.max. Sounds like 'uint', right? People make the mistake of thinking that is what uint is. But it is not. How would natint behave, in the type system? typeof (natint - natint) == int NOT natint !!! This would of course overflow if the result is too big to fit in an int. But the type would be correct. 1 - 2 == -1.
So if i is a natint the expression i-- would change the type of variable i on the fly to int ?
Nov 21 2014
prev sibling next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Nov 21, 2014 at 03:36:01PM +0000, Don via Digitalmars-d wrote:
[...]
 Suppose  D had a type 'natint', which could hold natural numbers in
 the range 0..uint.max.  Sounds like 'uint', right? People make the
 mistake of thinking that is what uint is. But it is not.
 
 How would natint behave, in the type system?
 
 typeof (natint - natint)  ==  int     NOT natint  !!!
Wrong. (uint.max - 0) == uint.max, which is of type uint. If you interpret it as int, you get a negative number, which is wrong. So your proposal breaks uint in even worse ways, in that now subtracting a smaller number from a larger number may overflow, whereas it wouldn't before. So that fixes nothing, you're just shifting the problem somewhere else. T -- Too many people have open minds but closed eyes.
Nov 21 2014
parent reply "Don" <x nospam.com> writes:
On Friday, 21 November 2014 at 15:50:05 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 On Fri, Nov 21, 2014 at 03:36:01PM +0000, Don via Digitalmars-d 
 wrote:
 [...]
 Suppose  D had a type 'natint', which could hold natural 
 numbers in
 the range 0..uint.max.  Sounds like 'uint', right? People make 
 the
 mistake of thinking that is what uint is. But it is not.
 
 How would natint behave, in the type system?
 
 typeof (natint - natint)  ==  int     NOT natint  !!!
Wrong. (uint.max - 0) == uint.max, which is of type uint.
It is not uint.max. It is natint.max. And yes, that's an overflow condition. Exactly the same as when you do int.max + int.max.
 If you
 interpret it as int, you get a negative number, which is wrong. 
 So your
 proposal breaks uint in even worse ways, in that now 
 subtracting a
 smaller number from a larger number may overflow, whereas it 
 wouldn't
 before. So that fixes nothing, you're just shifting the problem
 somewhere else.


 T
This is not a proposal!!!! I am just illustrating the difference between what people *think* uint does, vs what it actually does. The type that I think would be useful, would be a number in the range 0..int.max. It has no risk of underflow. To put it another way: natural numbers are a subset of mathematical integers. (the range 0..infinity) signed types are a subset of mathematical integers (the range -int.max .. int.max). unsigned types are not a subset of mathematical integers. They do not just have a restricted range. They have different semantics. The question of what happens when a range is exceeded, is a different question.
Nov 21 2014
next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Friday, 21 November 2014 at 16:12:19 UTC, Don wrote:
 On Friday, 21 November 2014 at 15:50:05 UTC, H. S. Teoh via 
 Digitalmars-d wrote:
 On Fri, Nov 21, 2014 at 03:36:01PM +0000, Don via 
 Digitalmars-d wrote:
 [...]
 Suppose  D had a type 'natint', which could hold natural 
 numbers in
 the range 0..uint.max.  Sounds like 'uint', right? People 
 make the
 mistake of thinking that is what uint is. But it is not.
 
 How would natint behave, in the type system?
 
 typeof (natint - natint)  ==  int     NOT natint  !!!
Wrong. (uint.max - 0) == uint.max, which is of type uint.
It is not uint.max. It is natint.max. And yes, that's an overflow condition. Exactly the same as when you do int.max + int.max.
 If you
 interpret it as int, you get a negative number, which is 
 wrong. So your
 proposal breaks uint in even worse ways, in that now 
 subtracting a
 smaller number from a larger number may overflow, whereas it 
 wouldn't
 before. So that fixes nothing, you're just shifting the problem
 somewhere else.


 T
This is not a proposal!!!! I am just illustrating the difference between what people *think* uint does, vs what it actually does. The type that I think would be useful, would be a number in the range 0..int.max. It has no risk of underflow. To put it another way: natural numbers are a subset of mathematical integers. (the range 0..infinity) signed types are a subset of mathematical integers (the range -int.max .. int.max). unsigned types are not a subset of mathematical integers. They do not just have a restricted range. They have different semantics.
I was under the impression that in D: uint = { x mod 2^32 | x ∈ Z_0 } int = { x - 2^31 | x ∈ uint } which matches the hardware.
Nov 21 2014
prev sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 21 November 2014 at 16:12:19 UTC, Don wrote:
 It is not uint.max. It is natint.max. And yes, that's an 
 overflow condition.

 Exactly the same as when you do int.max + int.max.
This depends on how you look at it. From a formal perspective assume zero as the base, then a predecessor function P and a successor function S. Then you have 0u - 1u + 2u ==> SSP0 Then you do a normalization where you cancel out successor and predecessor pairs and you get the result S0 ==> 1u. On the other hand if you end up with P0 the result should be bottom (error). In binary representation you need to collect the carry over N terms, so you need an extra accumulator which you can get by extending the precision by ~ log2(N) bits. Then do a masking of the most significant bits to check for over/underflow. Advanced for a compiler, but possible.
 The type that I think would be useful, would be a number in the 
 range 0..int.max.
 It has no risk of underflow.
Yep, from a correctness perspective length should be integer with a >=0 constraint. Ada also acknowledge this by having unsigned integers being 31 bits like you suggest. And now that most CPUs go 64 bit then a 63 bit integer would be the right choice for array length.
 unsigned types are not a subset of mathematical integers.

 They do not just have a restricted range. They have different 
 semantics.


 The question of what happens when a range is exceeded, is a 
 different question.
There is really no difference between signed and unsigned in principle since you only have an offset, but in practical programming 64 bits signed and 63 bits unsigned is enough for most situations with the advantage that you have the same bit representation with only one interpretation. What the semantics are depend on how you define the operators, right? So you can have both modular arithmetic and non-modular in the same type by providing more operators. This is after all how the hardware does it. Contrary to what is claimed by others in this thread the general hardware ALU does not default to modular arithmetic, it preserves resolution: 32bit + 32bit ==> 33bit result 32bit * 32bit ==> 64bit result Modular arithmetic is an artifact of the language, not the hardware.
Nov 23 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/21/2014 7:36 AM, Don wrote:
 On Friday, 21 November 2014 at 04:53:38 UTC, Walter Bright wrote:
 0 crossing bugs tend to show up much sooner, and often immediately.
You're missing the point here. The problem is that people are using 'uint' as if it were a positive integer type. Suppose D had a type 'natint', which could hold natural numbers in the range 0..uint.max. Sounds like 'uint', right? People make the mistake of thinking that is what uint is. But it is not. How would natint behave, in the type system? typeof (natint - natint) == int NOT natint !!! This would of course overflow if the result is too big to fit in an int. But the type would be correct. 1 - 2 == -1. But typeof (uint - uint ) == uint. The bit pattern is identical to the other case. But the type is wrong. It is for this reason that uint is not appropriate as a model for positive integers. Having warnings about mixing int and uint operations in relational operators is a bit misleading, because mixing signed and unsigned is not usually the real problem. Instead, those warnings a symptom of a type system mistake. You are quite right in saying that with a signed length, overflows can still occur. But, those are in principle detectable. The compiler could add runtime overflow checks for them, for example. But the situation for unsigned is not fixable, because it is a problem with the type system. By making .length unsigned, we are telling people that if .length is used in a subtraction expression, the type will be wrong. It is the incorrect use of the type system that is the underlying problem.
I believe I do understand the problem. As a practical matter, overflow checks are not going to be added for performance reasons. Also, in principle, uint-uint can generate a runtime check for underflow (i.e. the carry flag).
Nov 21 2014
parent reply "Don" <x nospam.com> writes:
On Friday, 21 November 2014 at 20:17:12 UTC, Walter Bright wrote:
 On 11/21/2014 7:36 AM, Don wrote:
 On Friday, 21 November 2014 at 04:53:38 UTC, Walter Bright 
 wrote:
 0 crossing bugs tend to show up much sooner, and often 
 immediately.
You're missing the point here. The problem is that people are using 'uint' as if it were a positive integer type. Suppose D had a type 'natint', which could hold natural numbers in the range 0..uint.max. Sounds like 'uint', right? People make the mistake of thinking that is what uint is. But it is not. How would natint behave, in the type system? typeof (natint - natint) == int NOT natint !!! This would of course overflow if the result is too big to fit in an int. But the type would be correct. 1 - 2 == -1. But typeof (uint - uint ) == uint. The bit pattern is identical to the other case. But the type is wrong. It is for this reason that uint is not appropriate as a model for positive integers. Having warnings about mixing int and uint operations in relational operators is a bit misleading, because mixing signed and unsigned is not usually the real problem. Instead, those warnings a symptom of a type system mistake. You are quite right in saying that with a signed length, overflows can still occur. But, those are in principle detectable. The compiler could add runtime overflow checks for them, for example. But the situation for unsigned is not fixable, because it is a problem with the type system. By making .length unsigned, we are telling people that if .length is used in a subtraction expression, the type will be wrong. It is the incorrect use of the type system that is the underlying problem.
I believe I do understand the problem. As a practical matter, overflow checks are not going to be added for performance reasons.
The performance overhead would be practically zero. All we would need to do, is restrict array slices such that the length cannot exceed ssize_t.max. This can only happen in the case where the element type has a size of 1, and only in the case of slicing a pointer, concatenation, and memory allocation. Making this restriction would have been unreasonable in the 8 and 16 bit days, but D doesn't support those. For 32 bits, this is an extreme corner case. For 64 bit, this condition never happens at all. In exchange, 99% of uses of unsigned would disappear from D code, and with it, a whole category of bugs.
 Also, in principle, uint-uint can generate a runtime check for 
 underflow (i.e. the carry flag).
No it cannot. The compiler does not have enough information to know if the value is intended to be positive integer, or an unsigned. That information is lost from the type system. Eg from C, wrapping of an unsigned type is not an error. It is perfectly defined behaviour. With signed types, it's undefined behaviour. To make this clear: I am not proposing that size_t should be changed. I am proposing that for .length returns a signed type, that for array slices is guaranteed to never be negative.
Nov 24 2014
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/24/14 2:20 AM, Don wrote:
 I am proposing that for .length returns a signed type, that for array
 slices is guaranteed to never be negative.
Assuming you do make the case this change is an improvement, do you believe it's worth the breakage it would create? -- Andrei
Nov 24 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/24/2014 2:20 AM, Don wrote:
 I believe I do understand the problem. As a practical matter, overflow checks
 are not going to be added for performance reasons.
The performance overhead would be practically zero. All we would need to do, is restrict array slices such that the length cannot exceed ssize_t.max. This can only happen in the case where the element type has a size of 1, and only in the case of slicing a pointer, concatenation, and memory allocation.
(length1 + length2) / 2
 In exchange, 99% of uses of unsigned would disappear from D code, and with it,
a
 whole category of bugs.
You're not proposing changing size_t, so I believe this statement is incorrect.
 Also, in principle, uint-uint can generate a runtime check for underflow (i.e.
 the carry flag).
No it cannot. The compiler does not have enough information to know if the value is intended to be positive integer, or an unsigned. That information is lost from the type system. Eg from C, wrapping of an unsigned type is not an error. It is perfectly defined behaviour. With signed types, it's undefined behaviour.
I know it's not an error. It can be defined to be an error, and the compiler can insert a runtime check. (I'm not proposing this, just saying it can be done.)
 To make this clear: I am not proposing that size_t should be changed.
 I am proposing that for .length returns a signed type, that for array slices is
 guaranteed to never be negative.
There'll be mass confusion if .length is not the same type as .sizeof
Nov 24 2014
next sibling parent "Don" <x nospam.com> writes:
On Monday, 24 November 2014 at 21:34:19 UTC, Walter Bright wrote:
 On 11/24/2014 2:20 AM, Don wrote:
 I believe I do understand the problem. As a practical matter, 
 overflow checks
 are not going to be added for performance reasons.
The performance overhead would be practically zero. All we would need to do, is restrict array slices such that the length cannot exceed ssize_t.max. This can only happen in the case where the element type has a size of 1, and only in the case of slicing a pointer, concatenation, and memory allocation.
(length1 + length2) / 2
That's not an issue with length, that's an issue with doing a calculation with an insufficient bit width. Unsigned doesn't actually help, it's still wrong. For unsigned values, if length1 = length2 = 0x8000_0000, that gives an answer of 0.
 In exchange, 99% of uses of unsigned would disappear from D 
 code, and with it, a
 whole category of bugs.
You're not proposing changing size_t, so I believe this statement is incorrect.
From the D code that I've seen, almost all uses of size_t come directly from the use of .length. But I concede (see below) that many of them come from .sizeof.
 Also, in principle, uint-uint can generate a runtime check 
 for underflow (i.e.
 the carry flag).
No it cannot. The compiler does not have enough information to know if the value is intended to be positive integer, or an unsigned. That information is lost from the type system. Eg from C, wrapping of an unsigned type is not an error. It is perfectly defined behaviour. With signed types, it's undefined behaviour.
I know it's not an error. It can be defined to be an error, and the compiler can insert a runtime check. (I'm not proposing this, just saying it can be done.)
But it can't do that, without turning unsigned into a different type. You'd be turning unsigned into a 'non-negative' which is a completely different type. This is my whole point. unsigned has no sign, you just get the raw bit pattern with no interpretation. This can mean several things, for example: 1. extended_non_negative is where you are using it for the positive range 0.. +0xFFFF_FFFF Then, overflow and underflow are errors. 2. a value where the highest bit is always 0. This can be safely used as int or uint. 3. Or, it can be modulo 2^^32 arithmetic, where wrapping is intended. 4. It can be part of extended precision arithmetic, where you want the carry flag. 5. It can be just a raw bit pattern. 6. The high bit can be a sign bit. This is a signed type, cast to uint. If the sign bit ever flips because of a carry, that's an error. The type system doesn't specify a meaning for the bit pattern. We've got a special type for case 6, but not for the others. The problem with unsigned is that since it can mean so many things, as if it were a union of these possibilities. So it's not strictly typed -- you need to careful, requiring some element of faith-based programming. And "signed-unsigned mismatch" is really where you are implicitly assuming that the unsigned value is case 2 or 6. But, if it is one of the other cases, you get nonsense. But those "signed unsigned mismatch" errors only catch some of the possible cases where you may forget which interpretation you are using, and act as if it were another one.
 To make this clear: I am not proposing that size_t should be 
 changed.
 I am proposing that for .length returns a signed type, that 
 for array slices is
 guaranteed to never be negative.
There'll be mass confusion if .length is not the same type as .sizeof
Ah, that is a good point. .sizeof is another source of unsigned. Again, quite unnecessarily, can a single type ever actually use up half of the memory space? (It was possible in the 8 and 16 bit days, but it's hard to imagine today). Even sillier, it is nearly always known at compile time! But still, .sizeof is low-level in a way that .length is not.
Nov 25 2014
prev sibling parent "Kagamin" <spam here.lot> writes:
On Monday, 24 November 2014 at 21:34:19 UTC, Walter Bright wrote:
 In exchange, 99% of uses of unsigned would disappear from D 
 code, and with it, a
 whole category of bugs.
You're not proposing changing size_t, so I believe this statement is incorrect.
The idea is to make unsigned types opt-in, a deliberate choice of individual programmers, not forced by the language. Positive signed integers convert to unsigned integers perfectly without losing information, so mixing types will work perfectly for those who request it.
Nov 25 2014
prev sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Thu, 20 Nov 2014 20:53:31 -0800
schrieb Walter Bright <newshound2 digitalmars.com>:

 On 11/20/2014 7:11 PM, Walter Bright wrote:
 On 11/20/2014 3:25 PM, bearophile wrote:
 Walter Bright:

 If that is changed to a signed type, then you'll have a same-only-different
 set of subtle bugs,
This is possible. Can you show some of the bugs, we can discuss them, and see if they are actually worse than the current situation.
All you're doing is trading 0 crossing for 0x7FFFFFFF crossing issues, and pretending the problems have gone away.
BTW, granted the 0x7FFFFFFF problems exhibit the bugs less often, but paradoxically this can make the bug worse, because then it only gets found much, much later in supposedly tested & robust code. 0 crossing bugs tend to show up much sooner, and often immediately.
+1000. This is also the reason we have a special float .init in D. There is no plethora of bugs to show, because they are under the radar. Signed types are only more convenient in the scripting language sense, like using double for everything and array indexing in JavaScript. -- Marco
Nov 21 2014
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 All you're doing is trading 0 crossing for 0x7FFFFFFF crossing 
 issues, and pretending the problems have gone away.
I'm not pretending anything. I am asking in practical programming what of the two solutions leads to leas problems/bugs. So far I've seen the unsigned solution and I've seen it's highly bug-prone.
 BTW, granted the 0x7FFFFFFF problems exhibit the bugs less 
 often, but paradoxically this can make the bug worse, because 
 then it only gets found much, much later in supposedly tested & 
 robust code.
Is this true? Do you have some examples of buggy code? Bye, bearophile
Nov 21 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/21/2014 12:10 AM, bearophile wrote:
 Walter Bright:

 All you're doing is trading 0 crossing for 0x7FFFFFFF crossing issues, and
 pretending the problems have gone away.
I'm not pretending anything. I am asking in practical programming what of the two solutions leads to leas problems/bugs. So far I've seen the unsigned solution and I've seen it's highly bug-prone.
I'm suggesting that having a bug and detecting the bug are two different things. The 0-crossing bug is easier to detect, but that doesn't mean that shifting the problem to 0x7FFFFFFF crossing bugs is making the bug count less.
 BTW, granted the 0x7FFFFFFF problems exhibit the bugs less often, but
 paradoxically this can make the bug worse, because then it only gets found
 much, much later in supposedly tested & robust code.
Is this true? Do you have some examples of buggy code?
http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html
Nov 21 2014
next sibling parent "Frank Like" <1150015857 qq.com> writes:
Mathematical difference between unsigned value,size comparison
should be done before in the right side of the equal sign
character.

such as:  l3 = (l1 >l2)? (l1 - l2):(l2 - l1);

If this work is done in druntime,small bug will be rarely.D will 
be a real system language.

Frank
Nov 21 2014
prev sibling next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 11/21/14, 5:45 AM, Walter Bright wrote:
 On 11/21/2014 12:10 AM, bearophile wrote:
 Walter Bright:

 All you're doing is trading 0 crossing for 0x7FFFFFFF crossing
 issues, and
 pretending the problems have gone away.
I'm not pretending anything. I am asking in practical programming what of the two solutions leads to leas problems/bugs. So far I've seen the unsigned solution and I've seen it's highly bug-prone.
I'm suggesting that having a bug and detecting the bug are two different things. The 0-crossing bug is easier to detect, but that doesn't mean that shifting the problem to 0x7FFFFFFF crossing bugs is making the bug count less.
 BTW, granted the 0x7FFFFFFF problems exhibit the bugs less often, but
 paradoxically this can make the bug worse, because then it only gets
 found
 much, much later in supposedly tested & robust code.
Is this true? Do you have some examples of buggy code?
http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html
"This bug can manifest itself for arrays whose length (in elements) is 2^30 or greater (roughly a billion elements)" How often does that happen in practice?
Nov 21 2014
next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 21 Nov 2014 11:17:06 -0300
Ary Borenszweig via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 "This bug can manifest itself for arrays whose length (in elements) is=20
 2^30 or greater (roughly a billion elements)"
=20
 How often does that happen in practice?
once in almost ten years is too often, as for me. i think that the answer must be "never". either no bug, or the code is broken. and one of the worst code is the code that "works most of the time", but still broken.
Nov 21 2014
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 11/21/14, 11:47 AM, ketmar via Digitalmars-d wrote:
 On Fri, 21 Nov 2014 11:17:06 -0300
 Ary Borenszweig via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 "This bug can manifest itself for arrays whose length (in elements) is
 2^30 or greater (roughly a billion elements)"

 How often does that happen in practice?
once in almost ten years is too often, as for me. i think that the answer must be "never". either no bug, or the code is broken. and one of the worst code is the code that "works most of the time", but still broken.
You see, if you don't use a BigNum for everything than you will always have hidden bugs, be it with int, uint or whatever. The thing is that with int bugs are much less frequent than with uint. So I don't know why you'd rather have uint than int...
Nov 21 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 21 Nov 2014 14:38:26 -0300
Ary Borenszweig via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 You see, if you don't use a BigNum for everything than you will always=20
 have hidden bugs, be it with int, uint or whatever.
why do you believe that i'm not aware of overflows and don't checking for that? i'm used to think about overflows and do overflow checking in production code since my Z80 days. and i don't believe that "infrequent bug" is better than "frequent bug". both are equally bad.
Nov 21 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/21/2014 10:05 AM, ketmar via Digitalmars-d wrote:
 why do you believe that i'm not aware of overflows and don't checking
 for that? i'm used to think about overflows and do overflow checking in
 production code since my Z80 days. and i don't believe that "infrequent
 bug" is better than "frequent bug". both are equally bad.
Having coded with 16 bit computers for decades, one gets used to thinking about and dealing with overflows :-)
Nov 21 2014
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Nov 21, 2014 at 10:57:44AM -0800, Walter Bright via Digitalmars-d wrote:
 On 11/21/2014 10:05 AM, ketmar via Digitalmars-d wrote:
why do you believe that i'm not aware of overflows and don't checking
for that? i'm used to think about overflows and do overflow checking
in production code since my Z80 days. and i don't believe that
"infrequent bug" is better than "frequent bug". both are equally bad.
Having coded with 16 bit computers for decades, one gets used to thinking about and dealing with overflows :-)
I used to write 8-bit assembly code on the 6502 (yeah I'm so dating myself), where overflows and underflows happen ALL THE TIME. :-) In fact, they happen so much, that I learned to embrace modulo arithmetic instead of fearing it. I would take advantage of value wrapping to shave off a few cycles here and a few cycles there -- they do add up, given that the CPU only ran at a meager 1MHz, so every little bit counts. Then in the 16-bit days, I wrote a sliding-window buffer using a 64kB buffer where the wraparound of the 16-bit index variable was a feature rather than a bug. :-) Basically, once it reaches within a certain distance from the end of the window, the next 32kB block of data was paged in from disk into the other half of the buffer, so as long as the operation didn't span more than 32kB each time, you can just increment the 16-bit index without needing to check for the end of the buffer -- it'd automatically wrap around to the beginning where the new 32kB block has been loaded once you go past the end. A truly circular buffer! :-P T -- That's not a bug; that's a feature!
Nov 21 2014
parent Marco Leise <Marco.Leise gmx.de> writes:
Am Fri, 21 Nov 2014 11:41:55 -0800
schrieb "H. S. Teoh via Digitalmars-d"
<digitalmars-d puremagic.com>:

 On Fri, Nov 21, 2014 at 10:57:44AM -0800, Walter Bright via Digitalmars-d
wrote:
 On 11/21/2014 10:05 AM, ketmar via Digitalmars-d wrote:
why do you believe that i'm not aware of overflows and don't checking
for that? i'm used to think about overflows and do overflow checking
in production code since my Z80 days. and i don't believe that
"infrequent bug" is better than "frequent bug". both are equally bad.
Having coded with 16 bit computers for decades, one gets used to thinking about and dealing with overflows :-)
I used to write 8-bit assembly code on the 6502 (yeah I'm so dating myself), where overflows and underflows happen ALL THE TIME. :-) In fact, they happen so much, that I learned to embrace modulo arithmetic instead of fearing it. I would take advantage of value wrapping to shave off a few cycles here and a few cycles there -- they do add up, given that the CPU only ran at a meager 1MHz, so every little bit counts. Then in the 16-bit days, I wrote a sliding-window buffer using a 64kB buffer where the wraparound of the 16-bit index variable was a feature rather than a bug. :-) Basically, once it reaches within a certain distance from the end of the window, the next 32kB block of data was paged in from disk into the other half of the buffer, so as long as the operation didn't span more than 32kB each time, you can just increment the 16-bit index without needing to check for the end of the buffer -- it'd automatically wrap around to the beginning where the new 32kB block has been loaded once you go past the end. A truly circular buffer! :-P T
I used to be a kid playing a GameBoy game called Mystic Quest (which some in Asia may know it as part of the Final Fantasy franchise). One day I got really greedy and spend days collecting gold. Vast amounts of gold. I learned which enemies drop the most and soon got 10000, 20000, 30000, 40000, 50000, 60000, ... NOOOOOOOOOOO! That game taught me two things. That Dodos are extinct and not checking for overflows is a painful experience. -- Marco
Nov 21 2014
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/21/14 6:17 AM, Ary Borenszweig wrote:
 On 11/21/14, 5:45 AM, Walter Bright wrote:
 On 11/21/2014 12:10 AM, bearophile wrote:
 Walter Bright:

 All you're doing is trading 0 crossing for 0x7FFFFFFF crossing
 issues, and
 pretending the problems have gone away.
I'm not pretending anything. I am asking in practical programming what of the two solutions leads to leas problems/bugs. So far I've seen the unsigned solution and I've seen it's highly bug-prone.
I'm suggesting that having a bug and detecting the bug are two different things. The 0-crossing bug is easier to detect, but that doesn't mean that shifting the problem to 0x7FFFFFFF crossing bugs is making the bug count less.
 BTW, granted the 0x7FFFFFFF problems exhibit the bugs less often, but
 paradoxically this can make the bug worse, because then it only gets
 found
 much, much later in supposedly tested & robust code.
Is this true? Do you have some examples of buggy code?
http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html
"This bug can manifest itself for arrays whose length (in elements) is 2^30 or greater (roughly a billion elements)" How often does that happen in practice?
Every time you read a DVD image :o). I should say that in my doctoral work it was often the case I'd have very large arrays. Andrei
Nov 21 2014
parent Ary Borenszweig <ary esperanto.org.ar> writes:
On 11/21/14, 1:32 PM, Andrei Alexandrescu wrote:
 On 11/21/14 6:17 AM, Ary Borenszweig wrote:
 On 11/21/14, 5:45 AM, Walter Bright wrote:
 On 11/21/2014 12:10 AM, bearophile wrote:
 Walter Bright:

 All you're doing is trading 0 crossing for 0x7FFFFFFF crossing
 issues, and
 pretending the problems have gone away.
I'm not pretending anything. I am asking in practical programming what of the two solutions leads to leas problems/bugs. So far I've seen the unsigned solution and I've seen it's highly bug-prone.
I'm suggesting that having a bug and detecting the bug are two different things. The 0-crossing bug is easier to detect, but that doesn't mean that shifting the problem to 0x7FFFFFFF crossing bugs is making the bug count less.
 BTW, granted the 0x7FFFFFFF problems exhibit the bugs less often, but
 paradoxically this can make the bug worse, because then it only gets
 found
 much, much later in supposedly tested & robust code.
Is this true? Do you have some examples of buggy code?
http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html
"This bug can manifest itself for arrays whose length (in elements) is 2^30 or greater (roughly a billion elements)" How often does that happen in practice?
Every time you read a DVD image :o). I should say that in my doctoral work it was often the case I'd have very large arrays.
Oh, sorry, I totally forgot that when you open a DVD with VLC it reads the whole thing to memory. </sarcasm>
Nov 21 2014
prev sibling parent "Don" <x nospam.com> writes:
On Friday, 21 November 2014 at 08:46:20 UTC, Walter Bright wrote:
 On 11/21/2014 12:10 AM, bearophile wrote:
 Walter Bright:

 All you're doing is trading 0 crossing for 0x7FFFFFFF 
 crossing issues, and
 pretending the problems have gone away.
I'm not pretending anything. I am asking in practical programming what of the two solutions leads to leas problems/bugs. So far I've seen the unsigned solution and I've seen it's highly bug-prone.
I'm suggesting that having a bug and detecting the bug are two different things. The 0-crossing bug is easier to detect, but that doesn't mean that shifting the problem to 0x7FFFFFFF crossing bugs is making the bug count less.
 BTW, granted the 0x7FFFFFFF problems exhibit the bugs less 
 often, but
 paradoxically this can make the bug worse, because then it 
 only gets found
 much, much later in supposedly tested & robust code.
Is this true? Do you have some examples of buggy code?
http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html
Changing signed to unsigned in that example does NOT fix the bug. It just means it fails with length = 2^^31 instead of length = 2^^30. uint a = 0x8000_0000u; uint b = 0x8000_0002u; assert( (a + b) /2 == 0); But actually I don't understand that article. The arrays are int, not char. Since length fits into 32 bits, the largest possible value is 2^^32-1. Therefore, for an int array, with 4 byte elements, the largest possible value is 2^^30-1. So I think the article is wrong. I don't think there is a bug in the code.
Nov 24 2014
prev sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 21 Nov 2014 08:10:55 +0000
bearophile via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 BTW, granted the 0x7FFFFFFF problems exhibit the bugs less=20
 often, but paradoxically this can make the bug worse, because=20
 then it only gets found much, much later in supposedly tested &=20
 robust code.
=20 Is this true? Do you have some examples of buggy code?
any code which does something like `if (a-b < 0)` is broken. it will work in most cases, but it is broken. you MUST to check values before subtracting. and if you must to do checks anyway, what is the reason of making length signed?
Nov 21 2014
parent reply "FrankLike" <1150015857 qq.com> writes:
On Friday, 21 November 2014 at 13:59:08 UTC, ketmar via 
Digitalmars-d wrote:

 any code which does something like `if (a-b < 0)` is broken. it
Modify it: https://github.com/D-Programming-Language/druntime/blob/master/src/core/checkedint.d Modify method: subu(uint ...) or subu(ulong ...) if(x<y) return y -x ; else return x -y; It will be not broken.
Nov 21 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 21 Nov 2014 14:55:45 +0000
FrankLike via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On Friday, 21 November 2014 at 13:59:08 UTC, ketmar via=20
 Digitalmars-d wrote:
=20
 any code which does something like `if (a-b < 0)` is broken. it
=20 Modify it:=20 https://github.com/D-Programming-Language/druntime/blob/master/src/core/c=
heckedint.d
=20
 Modify method: subu(uint ...) or subu(ulong ...)
 if(x<y)
 return y -x ;
 else
   return x -y;
=20
 It will be not broken.
and it will not do the same anymore too. it's not a fix at all.
Nov 21 2014
parent "FrankLike" <1150015857 qq.com> writes:
On Friday, 21 November 2014 at 15:13:22 UTC, ketmar via 
Digitalmars-d wrote:


 and it will not do the same anymore too. it's not a fix at all.
But it is a part of bugs. Sure,bug which is in mixing sign and unsign values should be fix.
Nov 21 2014
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Thursday, 20 November 2014 at 21:27:11 UTC, Walter Bright 
wrote:
 If that is changed to a signed type, then you'll have a 
 same-only-different set of subtle bugs
If people use signed length with unsigned integers, the length with implicitly convert to unsigned and behave like now, no difference.
 plus you'll break the intuition about these things from 
 everyone who has used C/C++ a lot.
C/C++ programmers disagree: http://critical.eschertech.com/2010/04/07/danger-unsigned-types-used-here/ Why do you think they can't handle signed integers?
Nov 21 2014
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 21 Nov 2014 09:23:01 +0000
Kagamin via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 C/C++ programmers disagree:=20
 http://critical.eschertech.com/2010/04/07/danger-unsigned-types-used-here/
 Why do you think they can't handle signed integers?
being C programmer i disagree that author of the article is C programmer.
Nov 21 2014
prev sibling next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Nov 20, 2014 at 12:02:42AM -0800, Walter Bright via Digitalmars-d wrote:
 On 11/19/2014 5:03 PM, H. S. Teoh via Digitalmars-d wrote:
If this kind of unsafe mixing wasn't allowed, or required explict
casts (to signify "yes I know what I'm doing and I'm prepared to face
the consequences"), I suspect that bearophile would be much happier
about this issue. ;-)
Explicit casts are worse than the problem - they can easily cause bugs.
Not any worse bugs than are currently *silently accepted* by the compiler!
 As for me personally, I like having a complete set of signed and
 unsigned integral types at my disposal. It's like having a full set of
 wrenches that are open end on one end and boxed on the other :-) Most
 of the time either end will work, but sometimes only one will.
 
 Now, if D were a non-systems language like Basic, Go or Java, unsigned
 types could be reasonably dispensed with. But D is a systems
 programming language, and it ought to have available types that match
 what the hardware supports.
Please note that I never suggested anywhere that we get rid of unsigned types. In fact, I think it was a right decision to include unsigned types in the language and to use an unsigned type for array length. What *could* be improved, is the prevention of obvious mistakes in *mixing* signed and unsigned types. Right now, D allows code like the following with no warning: uint x; int y; auto z = x - y; BTW, this one is the same in essence as an actual bug that I fixed in druntime earlier this year, so downplaying it as a mistake people make 'cos they confound computer math with math math is fallacious. T -- He who laughs last thinks slowest.
Nov 20 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/20/2014 7:52 AM, H. S. Teoh via Digitalmars-d wrote:
 What *could* be improved, is the prevention of obvious mistakes in
 *mixing* signed and unsigned types. Right now, D allows code like the
 following with no warning:

 	uint x;
 	int y;
 	auto z = x - y;

 BTW, this one is the same in essence as an actual bug that I fixed in
 druntime earlier this year, so downplaying it as a mistake people make
 'cos they confound computer math with math math is fallacious.
What about: uint x; auto z = x - 1; ?
Nov 20 2014
next sibling parent reply "FrankLike" <1150015857 qq.com> writes:
 What about:

     uint x;
     auto z = x - 1;

 ?
When mixing signed and unsigned, as signed, it maybe no mistaken. thhere is a small test,add 'cast(long)' before - operator,if it's auto add,maybe fine. ----- import std.stdio; void main() { size_t width = 10; size_t height = 20; writeln("before width is ",width," ,height is ",height); height -= 15; width -= cast(long)height; writeln("after width is ",width," ,height is ",height); } ----result: after width is 5 . it's ok. Frank
Nov 20 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/20/2014 3:37 PM, FrankLike wrote:
 What about:

     uint x;
     auto z = x - 1;

 ?
When mixing signed and unsigned, as signed, it maybe no mistaken.
I think you missed my question - is that legal code under H.S.Teoh's proposal?
Nov 20 2014
prev sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 20 Nov 2014 13:28:37 -0800
Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On 11/20/2014 7:52 AM, H. S. Teoh via Digitalmars-d wrote:
 What *could* be improved, is the prevention of obvious mistakes in
 *mixing* signed and unsigned types. Right now, D allows code like the
 following with no warning:

 	uint x;
 	int y;
 	auto z =3D x - y;

 BTW, this one is the same in essence as an actual bug that I fixed in
 druntime earlier this year, so downplaying it as a mistake people make
 'cos they confound computer math with math math is fallacious.
=20 What about: =20 uint x; auto z =3D x - 1; =20 ? =20
here z must be `long`. and for `ulong` compiler must emit error.
Nov 21 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/21/14 6:03 AM, ketmar via Digitalmars-d wrote:
 On Thu, 20 Nov 2014 13:28:37 -0800
 Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On 11/20/2014 7:52 AM, H. S. Teoh via Digitalmars-d wrote:
 What *could* be improved, is the prevention of obvious mistakes in
 *mixing* signed and unsigned types. Right now, D allows code like the
 following with no warning:

 	uint x;
 	int y;
 	auto z = x - y;

 BTW, this one is the same in essence as an actual bug that I fixed in
 druntime earlier this year, so downplaying it as a mistake people make
 'cos they confound computer math with math math is fallacious.
What about: uint x; auto z = x - 1; ?
here z must be `long`. and for `ulong` compiler must emit error.
Would you agree that that would break a substantial amount of correct D code? -- Andrei
Nov 21 2014
next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 21 Nov 2014 08:31:13 -0800
Andrei Alexandrescu via Digitalmars-d <digitalmars-d puremagic.com>
wrote:

 Would you agree that that would break a substantial amount of correct D=20
 code? -- Andrei
i don't think that code with possible int wrapping and `auto` is correct, so the answer is "no". bad code must be made bad.
Nov 21 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/21/14 8:57 AM, ketmar via Digitalmars-d wrote:
 On Fri, 21 Nov 2014 08:31:13 -0800
 Andrei Alexandrescu via Digitalmars-d <digitalmars-d puremagic.com>
 wrote:

 Would you agree that that would break a substantial amount of correct D
 code? -- Andrei
i don't think that code with possible int wrapping and `auto` is correct, so the answer is "no". bad code must be made bad.
I think you misunderstood the question. -- Andrei
Nov 21 2014
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 21 Nov 2014 17:45:11 -0800
Andrei Alexandrescu via Digitalmars-d <digitalmars-d puremagic.com>
wrote:

 On 11/21/14 8:57 AM, ketmar via Digitalmars-d wrote:
 On Fri, 21 Nov 2014 08:31:13 -0800
 Andrei Alexandrescu via Digitalmars-d <digitalmars-d puremagic.com>
 wrote:

 Would you agree that that would break a substantial amount of correct D
 code? -- Andrei
i don't think that code with possible int wrapping and `auto` is correct, so the answer is "no". bad code must be made bad.
=20 I think you misunderstood the question. -- Andrei
i don't think so. you have two questions here: is such code correct, and will it broke? if the answer to the first question is "no", then the second question has no sense. i keep thinking that such code is not correct (albeit it compiles ok), so nothing will break. at least this is how i understood your question. maybe you are right, and i didn't get it.
Nov 21 2014
prev sibling next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Nov 21, 2014 at 08:31:13AM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
 On 11/21/14 6:03 AM, ketmar via Digitalmars-d wrote:
On Thu, 20 Nov 2014 13:28:37 -0800
Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> wrote:

On 11/20/2014 7:52 AM, H. S. Teoh via Digitalmars-d wrote:
What *could* be improved, is the prevention of obvious mistakes in
*mixing* signed and unsigned types. Right now, D allows code like
the following with no warning:

	uint x;
	int y;
	auto z = x - y;

BTW, this one is the same in essence as an actual bug that I fixed
in druntime earlier this year, so downplaying it as a mistake
people make 'cos they confound computer math with math math is
fallacious.
What about: uint x; auto z = x - 1; ?
here z must be `long`. and for `ulong` compiler must emit error.
What if x==uint.max?
 Would you agree that that would break a substantial amount of correct
 D code? -- Andrei
Yeah I don't think it's a good idea for subtraction to yield a different type from its operands. Non-closure of operators (i.e., results are of a different type than operands) leads to a lot of frustration because you keep ending up with the wrong type, and inevitably people will just throw in random casts everywhere just to make things work. T -- We are in class, we are supposed to be learning, we have a teacher... Is it too much that I expect him to teach me??? -- RL
Nov 21 2014
prev sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 21 Nov 2014 09:08:54 -0800
"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> wrote:

What about:

      uint x;
      auto z =3D x - 1;

?
here z must be `long`. and for `ulong` compiler must emit error.
=20 What if x=3D=3Duint.max?
nothing bad, long is perfectly able to represent that.
 Would you agree that that would break a substantial amount of correct
 D code? -- Andrei
=20 Yeah I don't think it's a good idea for subtraction to yield a different type from its operands. Non-closure of operators (i.e., results are of a different type than operands) leads to a lot of frustration because you keep ending up with the wrong type, and inevitably people will just throw in random casts everywhere just to make things work.
not any subtraction, only that with `auto` vardecl.
Nov 21 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/21/2014 6:03 AM, ketmar via Digitalmars-d wrote:
 On Thu, 20 Nov 2014 13:28:37 -0800
 Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On 11/20/2014 7:52 AM, H. S. Teoh via Digitalmars-d wrote:
 What *could* be improved, is the prevention of obvious mistakes in
 *mixing* signed and unsigned types. Right now, D allows code like the
 following with no warning:

 	uint x;
 	int y;
 	auto z = x - y;

 BTW, this one is the same in essence as an actual bug that I fixed in
 druntime earlier this year, so downplaying it as a mistake people make
 'cos they confound computer math with math math is fallacious.
What about: uint x; auto z = x - 1; ?
here z must be `long`. and for `ulong` compiler must emit error.
So, any time an integer literal appears in an unsigned expression, the type of the expression becomes signed?
Nov 21 2014
next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Nov 21, 2014 at 10:59:13AM -0800, Walter Bright via Digitalmars-d wrote:
 On 11/21/2014 6:03 AM, ketmar via Digitalmars-d wrote:
On Thu, 20 Nov 2014 13:28:37 -0800
Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> wrote:

On 11/20/2014 7:52 AM, H. S. Teoh via Digitalmars-d wrote:
What *could* be improved, is the prevention of obvious mistakes in
*mixing* signed and unsigned types. Right now, D allows code like
the following with no warning:

	uint x;
	int y;
	auto z = x - y;

BTW, this one is the same in essence as an actual bug that I fixed
in druntime earlier this year, so downplaying it as a mistake
people make 'cos they confound computer math with math math is
fallacious.
What about: uint x; auto z = x - 1; ?
here z must be `long`. and for `ulong` compiler must emit error.
So, any time an integer literal appears in an unsigned expression, the type of the expression becomes signed?
And subtracting two ulongs gives a compile error?! Whoa, that is truly crippled. T -- Food and laptops don't mix.
Nov 21 2014
prev sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 21 Nov 2014 10:59:13 -0800
Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On 11/21/2014 6:03 AM, ketmar via Digitalmars-d wrote:
 On Thu, 20 Nov 2014 13:28:37 -0800
 Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On 11/20/2014 7:52 AM, H. S. Teoh via Digitalmars-d wrote:
 What *could* be improved, is the prevention of obvious mistakes in
 *mixing* signed and unsigned types. Right now, D allows code like the
 following with no warning:

 	uint x;
 	int y;
 	auto z =3D x - y;

 BTW, this one is the same in essence as an actual bug that I fixed in
 druntime earlier this year, so downplaying it as a mistake people make
 'cos they confound computer math with math math is fallacious.
What about: uint x; auto z =3D x - 1; ?
here z must be `long`. and for `ulong` compiler must emit error.
=20 =20 So, any time an integer literal appears in an unsigned expression, the ty=
pe of=20
 the expression becomes signed?
nope. only for `auto` expressions.
Nov 21 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/21/2014 11:36 AM, ketmar via Digitalmars-d wrote:
 On Fri, 21 Nov 2014 10:59:13 -0800
 Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On 11/21/2014 6:03 AM, ketmar via Digitalmars-d wrote:
 On Thu, 20 Nov 2014 13:28:37 -0800
 Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On 11/20/2014 7:52 AM, H. S. Teoh via Digitalmars-d wrote:
 What *could* be improved, is the prevention of obvious mistakes in
 *mixing* signed and unsigned types. Right now, D allows code like the
 following with no warning:

 	uint x;
 	int y;
 	auto z = x - y;

 BTW, this one is the same in essence as an actual bug that I fixed in
 druntime earlier this year, so downplaying it as a mistake people make
 'cos they confound computer math with math math is fallacious.
What about: uint x; auto z = x - 1; ?
here z must be `long`. and for `ulong` compiler must emit error.
So, any time an integer literal appears in an unsigned expression, the type of the expression becomes signed?
nope. only for `auto` expressions.
So 'auto' has different type rules for expressions than anywhere else in D? Consider: void foo(T)(T a) { ... } if (x - 1) foo(x - 1); if (auto a = x - 1) foo(a); and now foo() is instantiated with a different type? I'm afraid I can't sell that to anyone :-(
Nov 21 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 21 Nov 2014 11:52:29 -0800
Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 So 'auto' has different type rules for expressions than anywhere else in =
D?
=20
 Consider:
=20
      void foo(T)(T a) { ... }
=20
      if (x - 1) foo(x - 1);
      if (auto a =3D x - 1) foo(a);
=20
 and now foo() is instantiated with a different type?
=20
 I'm afraid I can't sell that to anyone :-(
the whole thing of `auto` is to let compiler decide. i won't be surprised if `a` becomes 80-bit real or bigint here -- that's up to compiler to decide which type will be able to hold the whole range. `auto` for me means "i don't care what type you'll choose, just do it for me and don't lose any bits." this can be some kind of structure with overloaded operators, for example.
Nov 21 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/21/2014 12:09 PM, ketmar via Digitalmars-d wrote:
 On Fri, 21 Nov 2014 11:52:29 -0800
 Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 So 'auto' has different type rules for expressions than anywhere else in D?

 Consider:

       void foo(T)(T a) { ... }

       if (x - 1) foo(x - 1);
       if (auto a = x - 1) foo(a);

 and now foo() is instantiated with a different type?

 I'm afraid I can't sell that to anyone :-(
the whole thing of `auto` is to let compiler decide. i won't be surprised if `a` becomes 80-bit real or bigint here -- that's up to compiler to decide which type will be able to hold the whole range. `auto` for me means "i don't care what type you'll choose, just do it for me and don't lose any bits." this can be some kind of structure with overloaded operators, for example.
'auto' doesn't mean "break my code if I refactor out expressions into temporaries".
Nov 21 2014
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 21 Nov 2014 12:35:31 -0800
Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 'auto' doesn't mean "break my code if I refactor out expressions into tem=
poraries". this can be easily avoided: just don't use `auto` for refactoring. i'm still thinking about `auto` as "any type that is able to hold the result". `uint` is obviously not able to hold the result of uint subtraction (as it can be negative, and uint can't). so when compiler automatically chooses the type which can't hold the resulting value, i see this as a design flaw and safety breaking feature. one of D flaws -- as i can see it -- is trying to be both a reasonably high-level and "close to metal". it's ok for "metal" language to use uint to hold that result and wrap. but it's not ok for high-level language, high-level language should free me of thinking about "wrapping", "overflow" and so on. i'm not telling that D is bad, i'm simply trying to tell that such confusions will raise again and again. "too far from metal" vs "too close to metal". i may just not get the whole concept, so i don't know what to expect in such cases. sometimes D amuses me with it's shamelessly breakage of principle of least astonishment. but yet again it very well can be flaw in my brains and not in D.
Nov 21 2014
prev sibling parent Nick Treleaven <ntrel-pub mybtinternet.com> writes:
On 20/11/2014 08:02, Walter Bright wrote:
 On 11/19/2014 5:03 PM, H. S. Teoh via Digitalmars-d wrote:
 If this kind of unsafe mixing wasn't allowed, or required explict casts
 (to signify "yes I know what I'm doing and I'm prepared to face the
 consequences"), I suspect that bearophile would be much happier about
 this issue. ;-)
Explicit casts are worse than the problem - they can easily cause bugs.
I recently explained to you that explicit casts are easily avoided using `import std.conv: signed, unsigned;`. D compilers badly need a way to detect bug-prone sign mixing. It is no exaggeration to say D is worse than C compilers in this regard. Usually we discuss how to compete with modern languages; here we are not even keeping up with C. It's disappointing this issue was pre-approved last year, but now neither you nor even Andrei seem particularly cognizant of the need to resolve it. If you belittle the problem, you discourage others from trying to solve it.
Nov 22 2014
prev sibling parent "Kagamin" <spam here.lot> writes:
On Thursday, 20 November 2014 at 01:05:51 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 However, the fact that you can freely mix signed and unsigned 
 types in
 unsafe ways without any warning, is a fly that spoils the soup.

 If this kind of unsafe mixing wasn't allowed, or required 
 explict casts
 (to signify "yes I know what I'm doing and I'm prepared to face 
 the
 consequences"), I suspect that bearophile would be much happier 
 about
 this issue. ;-)
If usage of unsigned types is not controlled, they will systematically mix with signed types, the mix becomes normal flow of the code. Disallowing normal flow of the code is even worse.
Nov 20 2014
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 11/19/14, 7:03 AM, Don wrote:
 On Tuesday, 18 November 2014 at 18:23:52 UTC, Marco Leise wrote:

 Weird consequence: using subtraction with an unsigned type is nearly
 always a bug.

 I wish D hadn't called unsigned integers 'uint'. They should have been
 called '__uint' or something. They should look ugly. You need a very,
 very good reason to use an unsigned type.

 We have a builtin type that is deadly but seductive.
I agree. An array's length makes sense as an unsigned ("an array can't have a negative length, right?") but it leads to the bugs you say. For example: ~~~ import std.stdio; void main() { auto a = [1, 2, 3]; auto b = [1, 2, 3, 4]; if (a.length - b.length > 0) { writeln("Can you spot the bug that easily?"); } } ~~~ Yes, it makes sense, but at the same time it leads to super unintuitive math operations being involved. Rust made the same mistake and now a couple of times I've seen bugs like these being reported. Never seen them in Java or .Net though. I wonder why...
Nov 19 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/19/14 10:09 AM, Ary Borenszweig wrote:
 On 11/19/14, 7:03 AM, Don wrote:
 On Tuesday, 18 November 2014 at 18:23:52 UTC, Marco Leise wrote:
>
 Weird consequence: using subtraction with an unsigned type is nearly
 always a bug.

 I wish D hadn't called unsigned integers 'uint'. They should have been
 called '__uint' or something. They should look ugly. You need a very,
 very good reason to use an unsigned type.

 We have a builtin type that is deadly but seductive.
I agree. An array's length makes sense as an unsigned ("an array can't have a negative length, right?") but it leads to the bugs you say. For example: ~~~ import std.stdio; void main() { auto a = [1, 2, 3]; auto b = [1, 2, 3, 4]; if (a.length - b.length > 0) { writeln("Can you spot the bug that easily?"); } } ~~~ Yes, it makes sense, but at the same time it leads to super unintuitive math operations being involved. Rust made the same mistake and now a couple of times I've seen bugs like these being reported. Never seen them in Java or .Net though. I wonder why...
There are related bugs in Java too, e.g. I remember one in binary search where (i + j) / 2 was wrong because of an overflow. Also, Java does have a package for unsigned integers so apparently it's necessary. Andrei
Nov 19 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 There are related bugs in Java too, e.g. I remember one in 
 binary search where (i + j) / 2 was wrong because of an 
 overflow.
This is possible in D too.
 Also, Java does have a package for unsigned integers so 
 apparently it's necessary.
This is irrelevant. No one here is saying that a system language should not have unsigned values. The discussion here is about the type of array lengths. Bye, bearophile
Nov 19 2014
next sibling parent reply "Matthias Bentrup" <matthias.bentrup googlemail.com> writes:
On Wednesday, 19 November 2014 at 20:40:53 UTC, bearophile wrote:
 Andrei Alexandrescu:

 There are related bugs in Java too, e.g. I remember one in 
 binary search where (i + j) / 2 was wrong because of an 
 overflow.
This is possible in D too.
 Also, Java does have a package for unsigned integers so 
 apparently it's necessary.
This is irrelevant. No one here is saying that a system language should not have unsigned values. The discussion here is about the type of array lengths. Bye, bearophile
The only signed types that are able to represent all possible array lengths on 64 bit systems are long double and cent.
Nov 19 2014
parent Marco Leise <Marco.Leise gmx.de> writes:
Am Wed, 19 Nov 2014 21:38:50 +0000
schrieb "Matthias Bentrup" <matthias.bentrup googlemail.com>:

 array lengths on 64 bit systems are long double and cent.
Last time I checked, null was a reserved address. ;) -- Marco
Nov 21 2014
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/19/14 12:40 PM, bearophile wrote:
 Andrei Alexandrescu:

 There are related bugs in Java too, e.g. I remember one in binary
 search where (i + j) / 2 was wrong because of an overflow.
This is possible in D too.
 Also, Java does have a package for unsigned integers so apparently
 it's necessary.
This is irrelevant. No one here is saying that a system language should not have unsigned values. The discussion here is about the type of array lengths.
I think we're in good shape with unsigned. -- Andrei
Nov 19 2014
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Nov 19, 2014 at 04:08:11PM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
 On 11/19/14 12:40 PM, bearophile wrote:
Andrei Alexandrescu:

There are related bugs in Java too, e.g. I remember one in binary
search where (i + j) / 2 was wrong because of an overflow.
This is possible in D too.
Also, Java does have a package for unsigned integers so apparently
it's necessary.
This is irrelevant. No one here is saying that a system language should not have unsigned values. The discussion here is about the type of array lengths.
I think we're in good shape with unsigned. -- Andrei
Implicit conversion between signed/unsigned is the fly that spoils the soup, and the source of subtle bugs that persistently crop up when dealing with size_t. The fact of the matter is that humans are error-prone, even when they are aware of the pitfalls of mixing signed / unsigned types, and currently the language is doing nothing to help prevent these sorts of mistakes. T -- Help a man when he is in trouble and he will remember you when he is in trouble again.
Nov 19 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/19/14 4:24 PM, H. S. Teoh via Digitalmars-d wrote:
 On Wed, Nov 19, 2014 at 04:08:11PM -0800, Andrei Alexandrescu via
Digitalmars-d wrote:
 On 11/19/14 12:40 PM, bearophile wrote:
 Andrei Alexandrescu:

 There are related bugs in Java too, e.g. I remember one in binary
 search where (i + j) / 2 was wrong because of an overflow.
This is possible in D too.
 Also, Java does have a package for unsigned integers so apparently
 it's necessary.
This is irrelevant. No one here is saying that a system language should not have unsigned values. The discussion here is about the type of array lengths.
I think we're in good shape with unsigned. -- Andrei
Implicit conversion between signed/unsigned is the fly that spoils the soup, and the source of subtle bugs that persistently crop up when dealing with size_t. The fact of the matter is that humans are error-prone, even when they are aware of the pitfalls of mixing signed / unsigned types, and currently the language is doing nothing to help prevent these sorts of mistakes.
That I partially, fractionally even, agree with. We agonized for a long time about what to do to improve on the state of the art back in 2007 - literally months I recall. Part of the conclusion was that reverting to int for object lengths would be a net negative. Andrei
Nov 19 2014
next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Nov 19, 2014 at 04:42:53PM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
 On 11/19/14 4:24 PM, H. S. Teoh via Digitalmars-d wrote:
On Wed, Nov 19, 2014 at 04:08:11PM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
On 11/19/14 12:40 PM, bearophile wrote:
Andrei Alexandrescu:

There are related bugs in Java too, e.g. I remember one in binary
search where (i + j) / 2 was wrong because of an overflow.
This is possible in D too.
Also, Java does have a package for unsigned integers so apparently
it's necessary.
This is irrelevant. No one here is saying that a system language should not have unsigned values. The discussion here is about the type of array lengths.
I think we're in good shape with unsigned. -- Andrei
Implicit conversion between signed/unsigned is the fly that spoils the soup, and the source of subtle bugs that persistently crop up when dealing with size_t. The fact of the matter is that humans are error-prone, even when they are aware of the pitfalls of mixing signed / unsigned types, and currently the language is doing nothing to help prevent these sorts of mistakes.
That I partially, fractionally even, agree with. We agonized for a long time about what to do to improve on the state of the art back in 2007 - literally months I recall. Part of the conclusion was that reverting to int for object lengths would be a net negative.
[...] Actually, I agree about using unsigned for object lengths. I think it's a sound decision -- why use a signed value for something that can never be negative? OTOH, what spoils this (hence the fly in soup reference), is the fact that you can now take these unsigned values and randomly mix them up with signed values without a single warning from the compiler. Even requiring a cast to signify "I know what I'm doing, just do as I say" would be an improvement over the current silent acceptance of questionable code like `if (x.length - y.length < 0) ...`. T -- I am a consultant. My job is to make your job redundant. -- Mr Tom
Nov 19 2014
prev sibling parent reply "FrankLike" <1150015857 qq.com> writes:
 That I partially, fractionally even, agree with. We agonized 
 for a long time about what to do to improve on the state of the 
 art back in 2007 - literally months I recall. Part of the 
 conclusion was that reverting to int for object lengths would 
 be a net negative.

 Andrei
All of these discussions, let me known how to do about 'length',D better than c,it's a system language. For WindowsAPI: cast(something)length ,and other modify it to size_t. Thank you all.
Nov 19 2014
parent Marco Leise <Marco.Leise gmx.de> writes:
Am Thu, 20 Nov 2014 07:42:20 +0000
schrieb "FrankLike" <1150015857 qq.com>:

 That I partially, fractionally even, agree with. We agonized 
 for a long time about what to do to improve on the state of the 
 art back in 2007 - literally months I recall. Part of the 
 conclusion was that reverting to int for object lengths would 
 be a net negative.

 Andrei
All of these discussions, let me known how to do about 'length',D better than c,it's a system language. For WindowsAPI: cast(something)length ,and other modify it to size_t. Thank you all.
The correct thing is to use for WindowsAPI: length.to!int It checks if the length actually fits into an int. -- Marco
Nov 21 2014
prev sibling parent reply "Sean Kelly" <sean invisibleduck.org> writes:
On Thursday, 20 November 2014 at 00:08:08 UTC, Andrei 
Alexandrescu wrote:
 I think we're in good shape with unsigned.
I'd actually prefer signed. Index-based algorithms can be tricky to write correctly with unsigned index values. The reason size_t is unsigned in Druntime is because I felt that half the memory range on 32-bit was potentially too small a maximum size in a systems language, and it's unsigned on 64-bit for the sake of consistency.
Nov 20 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/20/14 7:29 AM, Sean Kelly wrote:
 On Thursday, 20 November 2014 at 00:08:08 UTC, Andrei Alexandrescu wrote:
 I think we're in good shape with unsigned.
I'd actually prefer signed. Index-based algorithms can be tricky to write correctly with unsigned index values.
The most difficult pattern that comes to mind is the "long arrow" operator seen in backward iteration: void fun(int[] a) { for (auto i = a.length; i --> 0; ) { // use i } } Andrei
Nov 20 2014
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Andrei Alexandrescu"  wrote in message 
news:m4l711$1t39$1 digitalmars.com...

 The most difficult pattern that comes to mind is the "long arrow" operator 
 seen in backward iteration:

 void fun(int[] a)
 {
      for (auto i = a.length; i --> 0; )
      {
          // use i
      }
 }
Over the years most of my unsigned-related bugs have been from screwing up various loop conditions. Thankfully D solves this perfectly with: void fun(int[] a) { foreach_reverse(i, 0...a.length) { } } So I never have to write those again.
Nov 21 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Daniel Murphy:

 void fun(int[] a)
 {
    foreach_reverse(i, 0...a.length)
    {
    }
 }
Better (it's a workaround for a D design flaw that we're unwilling to fix): foreach_reverse(immutable i, 0...a.length) Bye, bearophile
Nov 21 2014
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"bearophile"  wrote in message news:rqyuiioyrrjgggctfpcx forum.dlang.org...

 Better (it's a workaround for a D design flaw that we're unwilling to 
 fix):

 foreach_reverse(immutable i, 0...a.length)
I know you feel that way, but I'd rather face the non-existent risk of accidentally mutating the induction variable than write immutable every time.
Nov 21 2014
parent "bearophile" <bearophileHUGS lycos.com> writes:
Daniel Murphy:

 foreach_reverse(immutable i, 0...a.length)
I know you feel that way, but I'd rather face the non-existent risk of accidentally mutating the induction variable than write immutable every time.
It's not non-existent :-) (And the right default for a modern language is to have immutable on default and mutable on request. If D doesn't have this quality, better to add immutable every damn time). Bye, bearophile
Nov 21 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/21/2014 12:16 AM, Daniel Murphy wrote:
 Over the years most of my unsigned-related bugs have been from screwing up
 various loop conditions.  Thankfully D solves this perfectly with:

 void fun(int[] a)
 {
     foreach_reverse(i, 0...a.length)
     {
     }
 }

 So I never have to write those again.
I thought everyone hated foreach_reverse! But, yeah, foreach and ranges+algorithms have virtually eliminated a large category of looping bugs.
Nov 21 2014
next sibling parent reply "Stefan Koch" <uplink.coder googlemail.com> writes:
On Friday, 21 November 2014 at 09:37:50 UTC, Walter Bright wrote:
 I thought everyone hated foreach_reverse!
I dislike foreach_reverse; 1. it's a keyword with an underscore in it; 2. complicates implementation of foreach and parsing. 3. key_word with under_score
Nov 21 2014
next sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
 On Friday, 21 November 2014 at 09:37:50 UTC, Walter Bright wrote:
 I thought everyone hated foreach_reverse!
Not me. It's ugly but it gets the job done. All I have to do is add '_reverse' and it just works! "Stefan Koch" wrote in message news:mmvuvkdfnvwezyvtcceq forum.dlang.org...
 I dislike foreach_reverse;
 1. it's a keyword with an underscore in it;
So what.
 2. complicates implementation of foreach and parsing.
The additional complexity is trivial.
 3. key_word with under_score
Don't care.
Nov 21 2014
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Friday, 21 November 2014 at 09:47:32 UTC, Stefan Koch wrote:
 On Friday, 21 November 2014 at 09:37:50 UTC, Walter Bright 
 wrote:
 I thought everyone hated foreach_reverse!
I dislike foreach_reverse; 1. it's a keyword with an underscore in it; 2. complicates implementation of foreach and parsing. 3. key_word with under_score
These are compiler implementation issue and all solvable. People don't give a shit about how the compiler work and rightly so. The language is made to fit need of the user, not the needs of the implementer.
Nov 21 2014
next sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"deadalnix"  wrote in message news:qhirkvbtoiomkyjjugiy forum.dlang.org...

 These are compiler implementation issue and all solvable. People don't 
 give a shit about how the compiler work and rightly so. The language is 
 made to fit need of the user, not the needs of the implementer.
Usually, although they start to care when the complexity results in a never-ending supply of bugs. foreach_reverse doesn't come anywhere near this fortunately.
Nov 21 2014
prev sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 22 Nov 2014 03:09:59 +0000
deadalnix via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On Friday, 21 November 2014 at 09:47:32 UTC, Stefan Koch wrote:
 On Friday, 21 November 2014 at 09:37:50 UTC, Walter Bright=20
 wrote:
 I thought everyone hated foreach_reverse!
I dislike foreach_reverse; 1. it's a keyword with an underscore in it; 2. complicates implementation of foreach and parsing. 3. key_word with under_score
=20 These are compiler implementation issue and all solvable. People=20 don't give a shit about how the compiler work and rightly so. The=20 language is made to fit need of the user, not the needs of the=20 implementer.
`foreach (auto n; ...)` anyone? and `foreach (; ...)`? nope. "cosmetic changes aren't needed". this is clearly "made for implementer". luckyly, it's not me who will try explain to newcomers why they has new variable declaration in `foreach` which looks like variable reusing, why they must invent new variable name for each nested `foreach` and so on. but please, don't tell me about "solvable" -- all this "solvable" only in the sense "make your own fork and fix it. ah, and support your fork. and don't forget that your code cannot be used with vanilla compiler anymore." ok for me, but for others?
Nov 22 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 I thought everyone hated foreach_reverse!
I love it! Bye, bearophile
Nov 21 2014
parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Fri, 21 Nov 2014 11:24:37 +0000
schrieb "bearophile" <bearophileHUGS lycos.com>:

 Walter Bright:
 
 I thought everyone hated foreach_reverse!
I love it! Bye, bearophile
Hey, it is a bit ugly, but I'd pick foreach_reverse (i; 0 .. length) anytime over import std.range; foreach (i; iota(length).retro()) -- Marco
Nov 21 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/21/14 12:22 PM, Marco Leise wrote:
 Am Fri, 21 Nov 2014 11:24:37 +0000
 schrieb "bearophile" <bearophileHUGS lycos.com>:

 Walter Bright:

 I thought everyone hated foreach_reverse!
I love it! Bye, bearophile
Hey, it is a bit ugly, but I'd pick foreach_reverse (i; 0 .. length) anytime over import std.range; foreach (i; iota(length).retro())
I agree, though "foreach (i; length.iota.retro)" is no slouch either! -- Andrei
Nov 21 2014
parent Marco Leise <Marco.Leise gmx.de> writes:
Am Fri, 21 Nov 2014 17:50:11 -0800
schrieb Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:

 I agree, though "foreach (i; length.iota.retro)" is no slouch either! -- 
 Andrei
Yes, no, well, it feels like too much science for a loop with a decrementing index instead of an incrementing, no matter how few parenthesis are used. It is not the place where I would want to introduce functional programming to someone who never saw D code before. That said, I'd also be uncertain if compilers transparently convert this to the equivalent of a reverse loop. -- Marco
Nov 22 2014
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 21 November 2014 at 09:37:50 UTC, Walter Bright wrote:
 On 11/21/2014 12:16 AM, Daniel Murphy wrote:
 Over the years most of my unsigned-related bugs have been from 
 screwing up
 various loop conditions.  Thankfully D solves this perfectly 
 with:

 void fun(int[] a)
 {
    foreach_reverse(i, 0...a.length)
    {
    }
 }

 So I never have to write those again.
I thought everyone hated foreach_reverse! But, yeah, foreach and ranges+algorithms have virtually eliminated a large category of looping bugs.
Well yeah, it is kind of ugly looking, and a language construct for that when we have retro in phobos... foreach_reverse is essentially dead weight in the spec.
Nov 21 2014
prev sibling next sibling parent "uri" <uri gmail.com> writes:
On Wednesday, 19 November 2014 at 18:09:11 UTC, Ary Borenszweig 
wrote:
 On 11/19/14, 7:03 AM, Don wrote:
 On Tuesday, 18 November 2014 at 18:23:52 UTC, Marco Leise 
 wrote:

 Weird consequence: using subtraction with an unsigned type is 
 nearly
 always a bug.

 I wish D hadn't called unsigned integers 'uint'. They should 
 have been
 called '__uint' or something. They should look ugly. You need 
 a very,
 very good reason to use an unsigned type.

 We have a builtin type that is deadly but seductive.
I agree. An array's length makes sense as an unsigned ("an array can't have a negative length, right?") but it leads to the bugs you say. For example: ~~~ import std.stdio; void main() { auto a = [1, 2, 3]; auto b = [1, 2, 3, 4]; if (a.length - b.length > 0) { writeln("Can you spot the bug that easily?"); } } ~~~ Yes, it makes sense, but at the same time it leads to super unintuitive math operations being involved. Rust made the same mistake and now a couple of times I've seen bugs like these being reported. Never seen them in Java or .Net though. I wonder why...
IMO array length should be unsigned but I'd like to see unsafe operators on unsigned types illegal. It is trivial to write (a.signed - b.signed) and it should be explicit in the code, i.e. not something that the compiler will do automatically behind the scenes. Cheers, uri
Nov 19 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/19/2014 10:09 AM, Ary Borenszweig wrote:
 I agree. An array's length makes sense as an unsigned ("an array can't have a
 negative length, right?") but it leads to the bugs you say. For example:

 ~~~
 import std.stdio;

 void main() {
    auto a = [1, 2, 3];
    auto b = [1, 2, 3, 4];
    if (a.length - b.length > 0) {
      writeln("Can you spot the bug that easily?");
Yes.
    }
 }
 ~~~

 Yes, it makes sense, but at the same time it leads to super unintuitive math
 operations being involved.
Computer math is not math math. It is its own beast, and if you're going to write in a systems programming language it is very important to learn how it works, or you'll be nothing but frustrated.
 Rust made the same mistake and now a couple of times I've seen bugs like these
 being reported. Never seen them in Java or .Net though. I wonder why...
D is meant to be easily used by C and C++ programmers. It follows the same model of signed/unsigned arithmetic and integral promotions. This is very, very deliberate. To change this would be a disaster. For example, in America we drive on the right. In Australia, they drive on the left. When I visit Australia, I know this, but when stepping out into the road I instinctively check my left for cars, step into the road, and my foot gets run over by a car coming from the right. I've had to be very careful as a pedestrian there, as my intuition would get me killed. Don't mess with systems programmers' intuitions. It'll cause more problems than it solves.
Nov 20 2014
next sibling parent "Kagamin" <spam here.lot> writes:
On Thursday, 20 November 2014 at 08:14:41 UTC, Walter Bright 
wrote:
 Computer math is not math math. It is its own beast, and if 
 you're going to write in a systems programming language it is 
 very important to learn how it works, or you'll be nothing but 
 frustrated.
Understanding how it works doesn't mean error prone practices must be forced everywhere. It's not like D can't work with signed types.
 Rust made the same mistake and now a couple of times I've seen 
 bugs like these
 being reported. Never seen them in Java or .Net though. I 
 wonder why...
D is meant to be easily used by C and C++ programmers. It follows the same model of signed/unsigned arithmetic and integral promotions. This is very, very deliberate. To change this would be a disaster.
If unsigned types exist, it doesn't mean they must be forced everywhere.
 For example, in America we drive on the right. In Australia, 
 they drive on the left. When I visit Australia, I know this, 
 but when stepping out into the road I instinctively check my 
 left for cars, step into the road, and my foot gets run over by 
 a car coming from the right. I've had to be very careful as a 
 pedestrian there, as my intuition would get me killed.

 Don't mess with systems programmers' intuitions. It'll cause 
 more problems than it solves.
Bad things can happen, but why make them more probable instead of trying to make them less probable?
Nov 20 2014
prev sibling parent reply "CraigDillabaugh" <craig.dillabaugh gmail.com> writes:
On Thursday, 20 November 2014 at 08:14:41 UTC, Walter Bright 
wrote:
clip
 For example, in America we drive on the right. In Australia, 
 they drive on the left. When I visit Australia, I know this, 
 but when stepping out into the road I instinctively check my 
 left for cars, step into the road, and my foot gets run over by 
 a car coming from the right. I've had to be very careful as a 
 pedestrian there, as my intuition would get me killed.

 Don't mess with systems programmers' intuitions. It'll cause 
 more problems than it solves.
I live in Quebec and my intuition always tells me to look both ways - because you never know :o)
Nov 21 2014
parent "Meta" <jared771 gmail.com> writes:
On Friday, 21 November 2014 at 16:48:35 UTC, CraigDillabaugh 
wrote:
 I live in Quebec and my intuition always tells me to look both 
 ways - because you never know :o)
While doing my driver's training years ago, my instructor half-jokingly warned us never to jaywalk in Quebec unless we have a death wish and want to hear all about chalices and tabernacles.
Nov 21 2014
prev sibling next sibling parent reply "Kagamin" <spam here.lot> writes:
On Tuesday, 18 November 2014 at 18:23:52 UTC, Marco Leise wrote:
 Aside from the size factor, I personally prefer unsigned types
 for countable stuff like array lengths. Mixed arithmetics
 decay to unsinged anyways and you don't need checks like
 `assert(idx >= 0)`.
Failing assert(-1 < arr.length) make little sense though, -1 can't be bigger than a non-negative number.
Nov 19 2014
parent Marco Leise <Marco.Leise gmx.de> writes:
Am Wed, 19 Nov 2014 10:42:30 +0000
schrieb "Kagamin" <spam here.lot>:

 On Tuesday, 18 November 2014 at 18:23:52 UTC, Marco Leise wrote:
 Aside from the size factor, I personally prefer unsigned types
 for countable stuff like array lengths. Mixed arithmetics
 decay to unsinged anyways and you don't need checks like
 `assert(idx >= 0)`.
Failing assert(-1 < arr.length) make little sense though, -1 can't be bigger than a non-negative number.
It makes little sense, right. -- Marco
Nov 21 2014
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Tuesday, 18 November 2014 at 18:23:52 UTC, Marco Leise wrote:
 Mixed arithmetics decay to unsinged anyways and you don't need 
 checks like `assert(idx >= 0)`.
What such assert gets you, what bound checking doesn't?
Nov 19 2014
parent Marco Leise <Marco.Leise gmx.de> writes:
Am Wed, 19 Nov 2014 11:01:12 +0000
schrieb "Kagamin" <spam here.lot>:

 On Tuesday, 18 November 2014 at 18:23:52 UTC, Marco Leise wrote:
 Mixed arithmetics decay to unsinged anyways and you don't need 
 checks like `assert(idx >= 0)`.
What such assert gets you, what bound checking doesn't?
It gets me the same when idx is an index into a D slice. -- Marco
Nov 21 2014
prev sibling parent "Sean Kelly" <sean invisibleduck.org> writes:
On Tuesday, 18 November 2014 at 14:24:18 UTC, FrankLike wrote:
 Many excellent projects such as dfl,dgui,tango, many 'length' 
 which type is 'int' or 'uint',they are D's,many people like 
 it.but they should migrate to 64 bit.So if 'length' type is 
 'int',they can work on 64 bit,but now,they must be modify for 
 'length''s type.
The type of 'length' has always been size_t, which is aliased to uint on x86 and ulong on x64. I think an argument could be made for using long instead of ulong, but the switch from unsigned to signed across bus widths could result in portability issues (when building an x64 program for x86).
Nov 18 2014
prev sibling next sibling parent "matovitch" <camille.brugel laposte.net> writes:
On Tuesday, 18 November 2014 at 12:33:52 UTC, FrankLike wrote:
 If you migrate your projct from x86 to x64,you will find the 
 length is error,you must modify it ,such as:
   int i= (something).length
 to
   size_t i = (something).length

 but now ,'int' is enough for use,not huge and not small,only 
 enough.
 'int' is easy to write,and most people are used to it.
 Most importantly easier to migrate code,if  'length''s return 
 value type is 'int'.

 Thank you all.
I'm using size_t and std::size_t in C/C++...but sure I am a bit weird/extremist.
Nov 18 2014
prev sibling parent reply "Jeremy DeHaan" <dehaan.jeremiah gmail.com> writes:
On Tuesday, 18 November 2014 at 12:33:52 UTC, FrankLike wrote:
 If you migrate your projct from x86 to x64,you will find the 
 length is error,you must modify it ,such as:
   int i= (something).length
 to
   size_t i = (something).length

 but now ,'int' is enough for use,not huge and not small,only 
 enough.
 'int' is easy to write,and most people are used to it.
 Most importantly easier to migrate code,if  'length''s return 
 value type is 'int'.

 Thank you all.
This is a weird thing to argue. just because an int is good enough for you does not mean that it is the best thing for all people.
Nov 18 2014
parent reply "David Eagen" <davideagen mailinator.com> writes:
Isn't the purpose of size_t is to be large enough to address all 
available memory? A negative value is not only too small but 
doesn't make sense when discussing lengths.

Correctness requires using size_t.
Nov 18 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 18 Nov 2014 17:59:04 +0000
David Eagen via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 Isn't the purpose of size_t is to be large enough to address all=20
 available memory? A negative value is not only too small but=20
 doesn't make sense when discussing lengths.
=20
 Correctness requires using size_t.
yes. besides, there is no such thing as "negative length", so it's somewhat... weird to use signed integer for length.
Nov 18 2014
next sibling parent "Kagamin" <spam here.lot> writes:
On Tuesday, 18 November 2014 at 18:03:35 UTC, ketmar via 
Digitalmars-d wrote:
 On Tue, 18 Nov 2014 17:59:04 +0000
 David Eagen via Digitalmars-d <digitalmars-d puremagic.com> 
 wrote:

 Isn't the purpose of size_t is to be large enough to address 
 all available memory? A negative value is not only too small 
 but doesn't make sense when discussing lengths.
 
 Correctness requires using size_t.
yes. besides, there is no such thing as "negative length", so it's somewhat... weird to use signed integer for length.
The reason is so that D won't mess with implicit signed-unsigned conversion, not negative length.
Nov 19 2014
prev sibling parent reply "Don" <x nospam.com> writes:
On Tuesday, 18 November 2014 at 18:03:35 UTC, ketmar via 
Digitalmars-d wrote:
 On Tue, 18 Nov 2014 17:59:04 +0000
 David Eagen via Digitalmars-d <digitalmars-d puremagic.com> 
 wrote:

 Isn't the purpose of size_t is to be large enough to address 
 all available memory? A negative value is not only too small 
 but doesn't make sense when discussing lengths.
 
 Correctness requires using size_t.
yes. besides, there is no such thing as "negative length", so it's somewhat... weird to use signed integer for length.
A length can certainly be negative. Just as a bank balance can be negative. It's just a number. If I have two pencils of length 10 cm and 15 cm, then the first one is -5 cm longer than the other. Of course any physical pencil is always of positive length, but that doesn't mean that typeof(pencil.length) can never be negative.
Nov 19 2014
next sibling parent "FrankLike" <1150015857 qq.com> writes:
 If I have two pencils of length 10 cm and 15 cm, then the first 
 one is -5 cm longer than the other.

 Of course any physical pencil is always of positive length, but 
 that doesn't mean that typeof(pencil.length) can never be 
 negative.
Right. 'int' is easy to use,is enough,and easy to migrate code to 64 bit.
Nov 19 2014
prev sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 19 Nov 2014 13:47:50 +0000
Don via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 yes. besides, there is no such thing as "negative length", so=20
 it's
 somewhat... weird to use signed integer for length.
=20 A length can certainly be negative. Just as a bank balance can be=20 negative. It's just a number.
what is the relation between bank balance and length? please, show me the array with -1 element, so i can see negative length myself. seems to me that you are using "length" as "quantity", but that isn't right.
 If I have two pencils of length 10 cm and 15 cm, then the first=20
 one is -5 cm longer than the other.
and again "length" is not a relation. show me pencil of length -10 cm. when you substractin lengthes, you got completely different type as a result, not "length" anymore. ah, that untyped real-life math! ;-)
 Of course any physical pencil is always of positive length, but=20
 that doesn't mean that typeof(pencil.length) can never be=20
 negative.
it can't be negative. if it can be negative, it is wrongly named, it's not "length".
Nov 19 2014
parent reply David Gileadi <gileadis NSPMgmail.com> writes:
On 11/19/14, 6:57 AM, ketmar via Digitalmars-d wrote:
 On Wed, 19 Nov 2014 13:47:50 +0000
 Don via Digitalmars-d <digitalmars-d puremagic.com> wrote:
 If I have two pencils of length 10 cm and 15 cm, then the first
 one is -5 cm longer than the other.
and again "length" is not a relation. show me pencil of length -10 cm. when you substractin lengthes, you got completely different type as a result, not "length" anymore. ah, that untyped real-life math! ;-)
To me the salient point is that this is not just a mess with real-life math but also with math in D: lengths are unsigned but people subtract them all the time. If they're (un)lucky this will return correct values for a while, but then someday the lengths may be reversed and the values will be hugely wrong: int[] a = [1, 2, 3]; int[] b = [5, 4, 3, 2, 1]; writefln("%s", b.length - a.length); // Yup, 2 writefln("%s", a.length - b.length); // WAT? 18446744073709551614 This is why I agree with Don that:
 Having arr.length return an unsigned type, is a dreadful language
 mistake.
Nov 19 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
David Gileadi:

     writefln("%s", b.length - a.length);  // Yup, 2
     writefln("%s", a.length - b.length);  // WAT? 
 18446744073709551614
Nowadays a better way to write such kind of code is using the Phobos "signed" function: writefln("%s", b.length.signed - a.length.signed); writefln("%s", a.length.signed - b.length.signed);
 This is why I agree with Don that:

 Having arr.length return an unsigned type, is a dreadful
language mistake.
This mistake is by design. Walter has resisted several times turning them into signed values, and even making size_t a type strongly different from uint/ulong. I don't agree with this design decision, but it's unlikely that Walter has changed his mind on it. So better to go on and discuss other things more likely to happen. Bye, bearophile
Nov 19 2014
parent reply David Gileadi <gileadis NSPMgmail.com> writes:
On 11/19/14, 9:12 AM, bearophile wrote:
 David Gileadi:

     writefln("%s", b.length - a.length);  // Yup, 2
     writefln("%s", a.length - b.length);  // WAT? 18446744073709551614
Nowadays a better way to write such kind of code is using the Phobos "signed" function: writefln("%s", b.length.signed - a.length.signed); writefln("%s", a.length.signed - b.length.signed);
But this requires the following knowledge: 1. That the signed function exists, and its location. As a casual D programmer I didn't know about it. 2. That there's a need for it at all, which requires knowing that length is unsigned. I did know this, but I bet in the heat of programming I'd easily forget it. In a semi-complex algorithm the bug could easily hide for a long time before biting.
 This is why I agree with Don that:

 Having arr.length return an unsigned type, is a dreadful
language mistake.
This mistake is by design. Walter has resisted several times turning them into signed values, and even making size_t a type strongly different from uint/ulong. I don't agree with this design decision, but it's unlikely that Walter has changed his mind on it. So better to go on and discuss other things more likely to happen.
Yes, I bet you're right about the likelihood of change.
Nov 19 2014
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
David Gileadi:

 But this requires the following knowledge:
 1. That the signed function exists, and its location. As a 
 casual D programmer I didn't know about it.
 2. That there's a need for it at all, which requires knowing 
 that length is unsigned. I did know this, but I bet in the heat 
 of programming I'd easily forget it. In a semi-complex 
 algorithm the bug could easily hide for a long time before 
 biting.
A solution for similar language design traps/mistakes is static analysis, with tools like Dscanner trained to recognize the troubling coding patterns, that should suggest workarounds (or to use better designed languages. But no language is perfect). Bye, bearophile
Nov 19 2014
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/19/2014 8:22 AM, David Gileadi wrote:
 2. That there's a need for it at all, which requires knowing that length is
 unsigned. I did know this, but I bet in the heat of programming I'd easily
 forget it. In a semi-complex algorithm the bug could easily hide for a long
time
 before biting.
If it was signed, you'd just have different issues hiding.
Nov 20 2014
prev sibling next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 19 Nov 2014 09:02:49 -0700
David Gileadi via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On 11/19/14, 6:57 AM, ketmar via Digitalmars-d wrote:
 On Wed, 19 Nov 2014 13:47:50 +0000
 Don via Digitalmars-d <digitalmars-d puremagic.com> wrote:
 If I have two pencils of length 10 cm and 15 cm, then the first
 one is -5 cm longer than the other.
and again "length" is not a relation. show me pencil of length -10 cm. when you substractin lengthes, you got completely different type as a result, not "length" anymore. ah, that untyped real-life math! ;-)
=20 To me the salient point is that this is not just a mess with real-life=20 math but also with math in D: lengths are unsigned but people subtract=20 them all the time. If they're (un)lucky this will return correct values=20 for a while, but then someday the lengths may be reversed and the values=
=20
 will be hugely wrong:
=20
      int[] a =3D [1, 2, 3];
      int[] b =3D [5, 4, 3, 2, 1];
=20
      writefln("%s", b.length - a.length);  // Yup, 2
      writefln("%s", a.length - b.length);  // WAT? 18446744073709551614
=20
 This is why I agree with Don that:
=20
  > Having arr.length return an unsigned type, is a dreadful language
  > mistake.
ah, let range checking catch that. sure, there are edge cases where range checking fails, but not so many. besides, overflows are possible with signed ints too, so what signed length does is simply hiding the bad code. any code reviewer must ring a bell when he sees length subtraction without prior checking, be it signed or unsigned. so there is no reason in negative lengthes anyway.
Nov 19 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
ketmar:

 ah, let range checking catch that.
No thanks, I prefer to not have bugs in the first place.
 besides, overflows are possible with signed ints too,
From my experience in coding in D they are far more unlikely than sign-related bugs of array lengths.
 so what signed length does is simply hiding the bad code.
Signed lengths avoids traps that are quite easy to fall into.
 any code reviewer must ring
 a bell when he sees length subtraction without prior checking,
 be it signed or unsigned.
The unsigned nature of array lengths is more tricky than that. They cause troubles even if you just compare (with <) a length with a signed value. Bye, bearophile
Nov 19 2014
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"bearophile"  wrote in message news:lkcltlokangpzzdzzfjg forum.dlang.org...

 From my experience in coding in D they are far more unlikely than 
 sign-related bugs of array lengths.
Here's a simple program to calculate the relative size of two files, that will not work correctly with unsigned lengths. module sizediff import std.file; import std.stdio; void main(string[] args) { assert(args.length == 3, "Usage: sizediff file1 file2"); auto l1 = args[1].read().length; auto l2 = args[2].read().length; writeln("Difference: ", l1 - l2); } The two ways this can fail (that I want to highlight) are: 1. If either file is too large to fit in a size_t the result will (probably) be wrong 2. If file2 is bigger than file1 the result will be wrong If length was signed, problem 2 would not exist, and problem 1 would be more likely to occur. I think it's clear that signed lengths would work for more possible realistic inputs. While this is just an example, a similar pattern occurs in real code whenever array/range lengths are subtracted.
Nov 21 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/21/2014 12:31 AM, Daniel Murphy wrote:
 Here's a simple program to calculate the relative size of two files, that will
 not work correctly with unsigned lengths.

 module sizediff

 import std.file;
 import std.stdio;

 void main(string[] args)
 {
     assert(args.length == 3, "Usage: sizediff file1 file2");
     auto l1 = args[1].read().length;
     auto l2 = args[2].read().length;
     writeln("Difference: ", l1 - l2);
 }

 The two ways this can fail (that I want to highlight) are:
 1. If either file is too large to fit in a size_t the result will (probably) be
 wrong
Presumably read() will throw if the size is larger than it can handle. If it doesn't, this code is not buggy, but read() is.
Nov 21 2014
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Walter Bright"  wrote in message news:m4mua1$shh$1 digitalmars.com...

 Presumably read() will throw if the size is larger than it can handle. If 
 it doesn't, this code is not buggy, but read() is.
You're right, but that's really not the point.
Nov 21 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/21/14 12:56 AM, Daniel Murphy wrote:
 "Walter Bright"  wrote in message news:m4mua1$shh$1 digitalmars.com...

 Presumably read() will throw if the size is larger than it can handle.
 If it doesn't, this code is not buggy, but read() is.
You're right, but that's really not the point.
What is your point? (Honest question.) Are you proposing that we make all array lengths signed? -- Andrei
Nov 21 2014
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Andrei Alexandrescu"  wrote in message 
news:m4nn38$1lau$2 digitalmars.com...

 What is your point? (Honest question.)
That using signed integers exclusively eliminates one class of bugs, while making another class only marginally more likely.
 Are you proposing that we make all array lengths signed?
No, I think that ship has sailed. But I recommend avoiding unsigned types for general arithmetic.
Nov 21 2014
next sibling parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Sat, 22 Nov 2014 06:34:11 +1100
schrieb "Daniel Murphy" <yebbliesnospam gmail.com>:

 "Andrei Alexandrescu"  wrote in message=20
 news:m4nn38$1lau$2 digitalmars.com...
=20
 What is your point? (Honest question.)
=20 That using signed integers exclusively eliminates one class of bugs, whil=
e=20
 making another class only marginally more likely.
=20
 Are you proposing that we make all array lengths signed?
=20 No, I think that ship has sailed. But I recommend avoiding unsigned type=
s=20
 for general arithmetic.=20
=20 I think it is more about getting into the right mind set. All hardware integer types are limited and need overflow checking. As someone using unsigned types all the time, all I need to keep in mind are two rules: 1) Overflow: uint number; =E2=80=A6 number =3D 10 * number + ch - '0'; It is handled with: if (number > uint.max / 10) if (number > uint.max - (ch - '0')) An underflow practically doesn't happen with unsigned arithmetic. 2) Subtraction Order Subtract the smaller value from the bigger one. a) Commonly one entity is of greater magnitude than the other: fileSize - offset length - idx b) If both entities are equal before the Lord I make them ordered to make rule 1) hold: if (fileSize1 > fileSize2) { // Do one thing } else { // Do the other thing } The length of an array is perfectly represented by a size_t. My goal is to do the technically correct thing and thereby make overflow bugs impossible. I.e. With unsigned types in general and size_t in particular you cannot pass anything that is prone to underflow/overflow. It is all natural numbers and any overflows must have happened already before the array got indexed. Inside opIndex, the unsigned types simplify the range checks (by the compiler or explicit) by removing the need to test for < 0. At the end of the day I find myself using unsigned types much more frequently than signed types because I find it easier to keep them in check and reason about. --=20 Marco
Nov 21 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/21/2014 1:33 PM, Marco Leise wrote:
 As someone using unsigned types all the time, all I need to
 keep in mind are two rules:

 1) Overflow:

    uint number;
    …
    number = 10 * number + ch - '0';

    It is handled with:
    if (number > uint.max / 10)
    if (number > uint.max - (ch - '0'))
You're better off with core.checkedint here, as not only is it correct, but (eventually) it will enable the compiler to optimize it to simply checking the carry flag.
Nov 21 2014
parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Fri, 21 Nov 2014 18:07:15 -0800
schrieb Walter Bright <newshound2 digitalmars.com>:

 On 11/21/2014 1:33 PM, Marco Leise wrote:
 As someone using unsigned types all the time, all I need to
 keep in mind are two rules:

 1) Overflow:

    uint number;
    =E2=80=A6
    number =3D 10 * number + ch - '0';

    It is handled with:
    if (number > uint.max / 10)
    if (number > uint.max - (ch - '0'))
=20 You're better off with core.checkedint here, as not only is it correct, b=
ut=20
 (eventually) it will enable the compiler to optimize it to simply checkin=
g the=20
 carry flag.
Ah right, I keep forgetting that module. By the way, are calls to core.checkedint inlined? Since they are in another module and not templated I'd think not. --=20 Marco
Nov 22 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/22/2014 1:07 PM, Marco Leise wrote:
 Am Fri, 21 Nov 2014 18:07:15 -0800
 You're better off with core.checkedint here, as not only is it correct, but
 (eventually) it will enable the compiler to optimize it to simply checking the
 carry flag.
Ah right, I keep forgetting that module.
It is brand new (!) so you're forgiven.
 By the way, are calls
 to core.checkedint inlined? Since they are in another module
 and not templated I'd think not.
Yes, since the import leaves the source for it in there.
Nov 22 2014
prev sibling parent "FrankLike" <1150015857 qq.com> writes:
On Friday, 21 November 2014 at 21:22:55 UTC, Marco Leise wrote:

 Inside opIndex, the unsigned types simplify the range checks
 (by the compiler or explicit) by removing the need to test for
 < 0.
 At the end of the day I find myself using unsigned types much
 more frequently than signed types because I find it easier to
 keep them in check and reason about.
Yes,I think so,except in individual cases.
Nov 22 2014
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/21/14 11:34 AM, Daniel Murphy wrote:
 "Andrei Alexandrescu"  wrote in message
 news:m4nn38$1lau$2 digitalmars.com...

 What is your point? (Honest question.)
That using signed integers exclusively eliminates one class of bugs, while making another class only marginally more likely.
 Are you proposing that we make all array lengths signed?
No, I think that ship has sailed. But I recommend avoiding unsigned types for general arithmetic.
That's reasonable. Also I agree that the discussion is moot. -- Andrei
Nov 21 2014
prev sibling next sibling parent reply "Frank Like" <1150015857 qq.com> writes:
 Here's a simple program to calculate the relative size of two 
 files, that will not work correctly with unsigned lengths.

 module sizediff;

 import std.file;
 import std.stdio;

 void main(string[] args)
 {
    assert(args.length == 3, "Usage: sizediff file1 file2");
    auto l1 = args[1].read().length;
    auto l2 = args[2].read().length;
    writeln("Difference: ", l1 - l2);
 }
This will be ok: writeln("Difference: ", (l1 >l2)? (l1 - l2):(l2 - l1)); If 'length''s type is not 'size_t',but is 'int' or 'long', it will be ok like this: import std.math; writeln("Difference: ", abs(l1 >l2)); Mathematical difference between unsigned value,size comparison should be done before in the right side of the equal sign character. If this work is done in druntime,D will be a real system language.
Nov 21 2014
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Frank Like"  wrote in message news:zhejapfebcvxnzrezcqj forum.dlang.org...

 If this work is done in druntime,D will be a real system language.
Sure, this is obviously the fundamental thing holding D back from being a _real_ system language.
Nov 21 2014
prev sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 21 Nov 2014 19:31:23 +1100
Daniel Murphy via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 "bearophile"  wrote in message news:lkcltlokangpzzdzzfjg forum.dlang.org.=
..
=20
 From my experience in coding in D they are far more unlikely than=20
 sign-related bugs of array lengths.
=20 Here's a simple program to calculate the relative size of two files, that=
=20
 will not work correctly with unsigned lengths.
=20
 module sizediff
=20
 import std.file;
 import std.stdio;
=20
 void main(string[] args)
 {
     assert(args.length =3D=3D 3, "Usage: sizediff file1 file2");
     auto l1 =3D args[1].read().length;
     auto l2 =3D args[2].read().length;
     writeln("Difference: ", l1 - l2);
 }
=20
 The two ways this can fail (that I want to highlight) are:
 1. If either file is too large to fit in a size_t the result will (probab=
ly)=20
 be wrong
 2. If file2 is bigger than file1 the result will be wrong
=20
 If length was signed, problem 2 would not exist, and problem 1 would be m=
ore=20
 likely to occur.  I think it's clear that signed lengths would work for m=
ore=20
 possible realistic inputs.
no, the problem 2 just becomes hidden. while the given code works most of the time, it is still broken.
Nov 21 2014
next sibling parent reply "Araq" <rumpf_a web.de> writes:
 no, the problem 2 just becomes hidden. while the given code 
 works most
 of the time, it is still broken.
You cannot handle stack overflow in C reliably or out of memory conditions so "fails in extreme edge cases" is true for every piece of software. "broken" is not a black-white thing. "Works most of the time" surely is much more useful than "doesn't work". Otherwise you would throw away your phone the first time you get a busy signal.
Nov 21 2014
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 21 Nov 2014 14:37:39 +0000
Araq via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 "broken" is not a black-white thing. "Works most of the time"
 surely is much more useful than "doesn't work". Otherwise you
 would throw away your phone the first time you get a busy signal.
"works most of the time" is the worst thing: the bug can be hidden for decades and then suddenly blows up stright into your face, making you wonder what happens with "good code". i will chose the code which "doesn't work" over "works most of the time" one: the first has a clearly visible problem, and the former has a carefully hidden problem. i prefer visible problems. btw, your phone example is totally wrong, 'case "busy" is a well-defined state. i for sure will throw the phone away if the phone accepts only *some* incoming calls and silently ignores some others (without me explicitly telling it to do so, of course). that's like a code that "works most of the time". but not in that time when they phoning you to tell that your house is on fire.
Nov 21 2014
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 11/21/14, 11:29 AM, ketmar via Digitalmars-d wrote:
 On Fri, 21 Nov 2014 19:31:23 +1100
 Daniel Murphy via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 "bearophile"  wrote in message news:lkcltlokangpzzdzzfjg forum.dlang.org...

  From my experience in coding in D they are far more unlikely than
 sign-related bugs of array lengths.
Here's a simple program to calculate the relative size of two files, that will not work correctly with unsigned lengths. module sizediff import std.file; import std.stdio; void main(string[] args) { assert(args.length == 3, "Usage: sizediff file1 file2"); auto l1 = args[1].read().length; auto l2 = args[2].read().length; writeln("Difference: ", l1 - l2); } The two ways this can fail (that I want to highlight) are: 1. If either file is too large to fit in a size_t the result will (probably) be wrong 2. If file2 is bigger than file1 the result will be wrong If length was signed, problem 2 would not exist, and problem 1 would be more likely to occur. I think it's clear that signed lengths would work for more possible realistic inputs.
no, the problem 2 just becomes hidden. while the given code works most of the time, it is still broken.
So how would you solve problem 2?
Nov 21 2014
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 21 Nov 2014 14:36:53 -0300
Ary Borenszweig via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On 11/21/14, 11:29 AM, ketmar via Digitalmars-d wrote:
 On Fri, 21 Nov 2014 19:31:23 +1100
 Daniel Murphy via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 "bearophile"  wrote in message news:lkcltlokangpzzdzzfjg forum.dlang.o=
rg...
  From my experience in coding in D they are far more unlikely than
 sign-related bugs of array lengths.
Here's a simple program to calculate the relative size of two files, t=
hat
 will not work correctly with unsigned lengths.

 module sizediff

 import std.file;
 import std.stdio;

 void main(string[] args)
 {
      assert(args.length =3D=3D 3, "Usage: sizediff file1 file2");
      auto l1 =3D args[1].read().length;
      auto l2 =3D args[2].read().length;
      writeln("Difference: ", l1 - l2);
 }

 The two ways this can fail (that I want to highlight) are:
 1. If either file is too large to fit in a size_t the result will (pro=
bably)
 be wrong
 2. If file2 is bigger than file1 the result will be wrong

 If length was signed, problem 2 would not exist, and problem 1 would b=
e more
 likely to occur.  I think it's clear that signed lengths would work fo=
r more
 possible realistic inputs.
no, the problem 2 just becomes hidden. while the given code works most of the time, it is still broken.
=20 So how would you solve problem 2?
with proper check before doing subtraction. or by switching to some Scheme compiler with full numeric tower.
Nov 21 2014
prev sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Wednesday, 19 November 2014 at 16:02:50 UTC, David Gileadi 
wrote:
 On 11/19/14, 6:57 AM, ketmar via Digitalmars-d wrote:
 On Wed, 19 Nov 2014 13:47:50 +0000
 Don via Digitalmars-d <digitalmars-d puremagic.com> wrote:
 If I have two pencils of length 10 cm and 15 cm, then the 
 first
 one is -5 cm longer than the other.
and again "length" is not a relation. show me pencil of length -10 cm. when you substractin lengthes, you got completely different type as a result, not "length" anymore. ah, that untyped real-life math! ;-)
To me the salient point is that this is not just a mess with real-life math but also with math in D: lengths are unsigned but people subtract them all the time. If they're (un)lucky this will return correct values for a while, but then someday the lengths may be reversed and the values will be hugely wrong: int[] a = [1, 2, 3]; int[] b = [5, 4, 3, 2, 1]; writefln("%s", b.length - a.length); // Yup, 2 writefln("%s", a.length - b.length); // WAT? 18446744073709551614 This is why I agree with Don that:
 Having arr.length return an unsigned type, is a dreadful
language
 mistake.
I'd say length being unsigned is fine. The real mistake is that the difference between two unsigned values isn't signed, which would be the most "correct" behaviour. Let people cast the result if they want wrapping (or better, use a helper function to document the intentiion).
Nov 19 2014
parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Wed, 19 Nov 2014 18:20:24 +0000
schrieb "Marc Sch=C3=BCtz" <schuetzm gmx.net>:

 I'd say length being unsigned is fine. The real mistake is that=20
 the difference between two unsigned values isn't signed, which=20
 would be the most "correct" behaviour.
Now take my position where I explicitly write code relying on the fact that `bigger - smaller` yields correct results. uint bigger =3D uint.max; uint smaller =3D 2; if (bigger > smaller) { auto added =3D bigger - smaller; // Now 'added' is an int with the value -3 ! } else { auto removed =3D smaller - bigger; } In fact checking which value is larger is the only way to handle the full result range of subtracting two machine integers which is ~2 times larger than what the original type can handle: T.min - T.max .. T.max - T.min This is one reason why I'd like to just keep working with the original unsigned type, but split the range around the positive/negative pivot with an if-else. Implicit conversion of unsigned subtractions to signed values would make the above code unnecessarily hard.
 Let people cast the result=20
 if they want wrapping (or better, use a helper function to=20
 document the intentiion).
--=20 Marco
Nov 21 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/21/14 1:55 PM, Marco Leise wrote:
 Am Wed, 19 Nov 2014 18:20:24 +0000
 schrieb "Marc Schütz" <schuetzm gmx.net>:

 I'd say length being unsigned is fine. The real mistake is that
 the difference between two unsigned values isn't signed, which
 would be the most "correct" behaviour.
Now take my position where I explicitly write code relying on the fact that `bigger - smaller` yields correct results. uint bigger = uint.max; uint smaller = 2; if (bigger > smaller) { auto added = bigger - smaller; // Now 'added' is an int with the value -3 ! } else { auto removed = smaller - bigger; }
Interesting insight. Thanks for the many analytical examples you're giving in this thread. -- Andrei
Nov 21 2014
parent "FrankLike" <1150015857 qq.com> writes:
On Saturday, 22 November 2014 at 01:57:05 UTC, Andrei 
Alexandrescu wrote:
 On 11/21/14 1:55 PM, Marco Leise wrote:
 Am Wed, 19 Nov 2014 18:20:24 +0000
 schrieb "Marc Schütz" <schuetzm gmx.net>:

 I'd say length being unsigned is fine. The real mistake is 
 that
 the difference between two unsigned values isn't signed, which
 would be the most "correct" behaviour.
Now take my position where I explicitly write code relying on the fact that `bigger - smaller` yields correct results. uint bigger = uint.max; uint smaller = 2; if (bigger > smaller) { auto added = bigger - smaller; // Now 'added' is an int with the value -3 ! } else { auto removed = smaller - bigger; }
Interesting insight. Thanks for the many analytical examples you're giving in this thread. -- Andrei
It's right. ------smalltest---------------- import std.stdio; void main() { uint a =100; int b =80; auto c = a-b; auto d = b-a; writeln("c is ",c,", c's type is ",typeid(c)); writeln("d is ",d,", d's type is ",typeid(d)); auto e = b- a; writeln("e is ",e," e's type is ",typeid(e)); auto f = cast(int)b- cast(int)a; writeln("f is ",f," f's type is ",typeid(f)); } -------------end----------------------------- Only c and f's result is ok.
Nov 21 2014
prev sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Friday, 21 November 2014 at 21:44:25 UTC, Marco Leise wrote:
 Am Wed, 19 Nov 2014 18:20:24 +0000
 schrieb "Marc Schütz" <schuetzm gmx.net>:

 I'd say length being unsigned is fine. The real mistake is 
 that the difference between two unsigned values isn't signed, 
 which would be the most "correct" behaviour.
Now take my position where I explicitly write code relying on the fact that `bigger - smaller` yields correct results. uint bigger = uint.max; uint smaller = 2; if (bigger > smaller) { auto added = bigger - smaller; // Now 'added' is an int with the value -3 ! } else { auto removed = smaller - bigger; } In fact checking which value is larger is the only way to handle the full result range of subtracting two machine integers which is ~2 times larger than what the original type can handle: T.min - T.max .. T.max - T.min This is one reason why I'd like to just keep working with the original unsigned type, but split the range around the positive/negative pivot with an if-else. Implicit conversion of unsigned subtractions to signed values would make the above code unnecessarily hard.
Yes, that's true. However, I doubt that this is a common case. I'd say that when two values are to be subtracted (signed or unsigned), and there's no knowledge about which one is larger, it's more useful to get a signed difference. This should be correct in most cases, because I believe it is more likely that the two values are close to each other. It only becomes a problem when they're an opposite sides of the value range. Unfortunately, no matter how you turn it, there will always be corner cases that a) will be wrong and b) the compiler will allow silently. So the question becomes one of preferences between usefulness for common use cases, ease of detection of errors, and compatibility.
Nov 22 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 22 November 2014 at 11:12:06 UTC, Marc Schütz wrote:
 I'd say that when two values are to be subtracted (signed or 
 unsigned), and there's no knowledge about which one is larger, 
 it's more useful to get a signed difference. This should be 
 correct in most cases, because I believe it is more likely that 
 the two values are close to each other. It only becomes a 
 problem when they're an opposite sides of the value range.
Not being able to decrement unsigned types would be a disaster. Think about unsigned integers as an enumeration. You should be able to both take the predecessor and successor of the value. This is also in line with how you formalize natural numbers in math: 0 == zero 1 == successor(zero) 2 == successor(successor(zero)) This is basically a unary representation of natural numbers and it allows both addition and subtraction. Unsigned int should be considered a binary representation of the same capped at max value. Bearophile has given a sensible solution a long time ago, make type coercion explicit and add a weaker coercion operator. That operator should prevent senseless type coercion, but allow system-level-coercion over signedness. Problem fixed.
Nov 22 2014