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
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
Kagamin:
You can't change coding practice by introducing a new type.
We can try to change coding practice introducing new types :-)
Bye,
bearophile
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
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
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
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
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
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
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
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
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
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
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
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
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
On Friday, 21 November 2014 at 17:23:51 UTC, Marco Leise wrote:
Am Thu, 20 Nov 2014 08:18:23 +
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
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 0x7FFF
crossing issues, and
pretending the problems have gone away.
I'm not pretending anything. I am asking in
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
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
On Mon, 24 Nov 2014 12:54:58 +
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.
signature.asc
Description: PGP signature
On Mon, 24 Nov 2014 12:54:58 +
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.
signature.asc
Description: PGP signature
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
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
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
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
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
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
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
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
On Monday, 24 November 2014 at 16:00:53 UTC, ketmar via
Digitalmars-d wrote:
On Mon, 24 Nov 2014 12:54:58 +
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.
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
On Friday, 21 November 2014 at 21:44:25 UTC, Marco Leise wrote:
Am Wed, 19 Nov 2014 18:20:24 +
schrieb Marc Schütz schue...@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
On Sat, 22 Nov 2014 03:09:59 +
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
wrote:
I thought everyone hated foreach_reverse!
I dislike
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
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
Am Fri, 21 Nov 2014 17:50:11 -0800
schrieb Andrei Alexandrescu seewebsiteforem...@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
FrankLike wrote in message news:musbvhmuuhhvetovx...@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
H. S. Teoh via Digitalmars-d wrote in message
news:mailman.2156.1416499421.9932.digitalmar...@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
Walter Bright:
All you're doing is trading 0 crossing for 0x7FFF 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
Walter Bright wrote in message news:m4mggi$e1h$1...@digitalmars.com...
BTW, granted the 0x7FFF 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
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
bearophile wrote in message news:lkcltlokangpzzdzz...@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
On 11/21/2014 12:10 AM, Daniel Murphy wrote:
Walter Bright wrote in message news:m4mggi$e1h$1...@digitalmars.com...
BTW, granted the 0x7FFF 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
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
On 11/21/2014 12:10 AM, bearophile wrote:
Walter Bright:
All you're doing is trading 0 crossing for 0x7FFF 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.
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
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
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.
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,
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;
On Friday, 21 November 2014 at 04:53:38 UTC, Walter Bright wrote:
BTW, granted the 0x7FFF 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
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
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
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
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
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
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
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
bearophile wrote in message news:rqyuiioyrrjgggctf...@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
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:mmvuvkdfnvwezyvtc...@forum.dlang.org...
I
Frank Like wrote in message news:zhejapfebcvxnzrez...@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.
Walter Bright:
I thought everyone hated foreach_reverse!
I love it!
Bye,
bearophile
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
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
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
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,
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
On Thu, 20 Nov 2014 15:40:39 +
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
On Fri, 21 Nov 2014 08:10:55 +
bearophile via Digitalmars-d digitalmars-d@puremagic.com wrote:
BTW, granted the 0x7FFF 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
On Fri, 21 Nov 2014 09:23:01 +
Kagamin via Digitalmars-d digitalmars-d@puremagic.com wrote:
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?
being C programmer i disagree that author
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
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 0x7FFF crossing
issues, and
pretending the problems have gone away.
I'm not pretending anything. I am asking in practical programming what
of
On Fri, 21 Nov 2014 19:31:23 +1100
Daniel Murphy via Digitalmars-d digitalmars-d@puremagic.com wrote:
bearophile wrote in message news:lkcltlokangpzzdzz...@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
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
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
On Fri, 21 Nov 2014 14:37:39 +
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
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 ...)
On Fri, 21 Nov 2014 14:55:45 +
FrankLike via Digitalmars-d digitalmars-d@puremagic.com wrote:
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:
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.
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
On Fri, Nov 21, 2014 at 03:36:01PM +, 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
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
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.
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 +, 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
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*
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
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 0x7FFF crossing
issues, and
pretending the problems have gone away.
I'm not pretending anything. I
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,
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
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
Am Wed, 19 Nov 2014 10:22:49 +
schrieb Dominikus Dittes Scherkl
dominikus.sche...@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 ℕ in my code for
brevity and coolness)
No, this is far from the
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
Am Thu, 20 Nov 2014 08:18:23 +
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
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:lkcltlokangpzzdzz...@forum.dlang.org...
From my experience in coding in D they are far more unlikely
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
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 0x7FFF crossing
issues, and
pretending the problems
Am Fri, 21 Nov 2014 16:32:20 +
schrieb Wyatt wyatt@gmail.com:
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
Am Thu, 20 Nov 2014 20:53:31 -0800
schrieb Walter Bright newshou...@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,
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
have hidden bugs, be it with int, uint or whatever.
why do you believe that i'm not aware of overflows and don't
1 - 100 of 221 matches
Mail list logo
