On Thu, 8 Sep 2005 19:25:01 -0700, Walter Bright wrote:

> "David L. Davis" <SpottedTiger@yahoo.com> wrote in message news:dfnfsc$tg6$1@digitaldaemon.com...
>> Walter thank you for doing the Bugs/4750 fix, but I think it's still a bit broken. Because, if a negative value compares again ulong.min it still
> gives the
>> wrong result as the example code below shows.
> 
> Unfortunately, that's the C integral promotion rules at work. If either operand is of unsigned type, then the result become an unsigned comparison.

Yes, one must not use common sense here. Its obvious that when a coder wants to compare a potentially negative value with a guaranteed positive value that she really meant to interpret the bit pattern of the signed value as if it was an unsigned value. Stupid to think otherwise, no?

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
9/09/2005 1:53:52 PM

"Derek Parnell" <derek@psych.ward> wrote in message news:1sxotcg1idyvy$.1n1zgkwiqw7xg$.dlg@40tude.net...
> On Thu, 8 Sep 2005 19:25:01 -0700, Walter Bright wrote:
>
> > "David L. Davis" <SpottedTiger@yahoo.com> wrote in message news:dfnfsc$tg6$1@digitaldaemon.com...
> >> Walter thank you for doing the Bugs/4750 fix, but I think it's still a
bit
> >> broken. Because, if a negative value compares again ulong.min it still
> > gives the
> >> wrong result as the example code below shows.
> >
> > Unfortunately, that's the C integral promotion rules at work. If either operand is of unsigned type, then the result become an unsigned
comparison.
>
> Yes, one must not use common sense here. Its obvious that when a coder wants to compare a potentially negative value with a guaranteed positive value that she really meant to interpret the bit pattern of the signed value as if it was an unsigned value. Stupid to think otherwise, no?

The trouble with such rules is they've become deeply embedded in the C/C++ programmer's psyche. The difference in behavior shows up in the corner cases. This means that if one relies on one's tried and true instincts about how things work, they'll fail oddly. Worse, it would make it impractical to convert existing C/C++ code to D that had non-trivial integer calculations in it.

On Thu, 8 Sep 2005 23:20:32 -0700, Walter Bright wrote:

> "Derek Parnell" <derek@psych.ward> wrote in message news:1sxotcg1idyvy$.1n1zgkwiqw7xg$.dlg@40tude.net...
>> On Thu, 8 Sep 2005 19:25:01 -0700, Walter Bright wrote:
>>
>>> "David L. Davis" <SpottedTiger@yahoo.com> wrote in message news:dfnfsc$tg6$1@digitaldaemon.com...
>>>> Walter thank you for doing the Bugs/4750 fix, but I think it's still a
> bit
>>>> broken. Because, if a negative value compares again ulong.min it still
>>> gives the
>>>> wrong result as the example code below shows.
>>>
>>> Unfortunately, that's the C integral promotion rules at work. If either operand is of unsigned type, then the result become an unsigned
> comparison.
>>
>> Yes, one must not use common sense here. Its obvious that when a coder wants to compare a potentially negative value with a guaranteed positive value that she really meant to interpret the bit pattern of the signed value as if it was an unsigned value. Stupid to think otherwise, no?
> 
> The trouble with such rules is they've become deeply embedded in the C/C++ programmer's psyche. The difference in behavior shows up in the corner cases. This means that if one relies on one's tried and true instincts about how things work, they'll fail oddly. Worse, it would make it impractical to convert existing C/C++ code to D that had non-trivial integer calculations in it.

I understand. I keep forgetting that D is evolutionary and not revolutionary. It must keep it's 'appendix'.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
9/09/2005 4:52:08 PM

Walter Bright wrote:
> "Derek Parnell" <derek@psych.ward> wrote in message news:1sxotcg1idyvy$.1n1zgkwiqw7xg$.dlg@40tude.net...
>> On Thu, 8 Sep 2005 19:25:01 -0700, Walter Bright wrote:
>> 
>>> "David L. Davis" <SpottedTiger@yahoo.com> wrote in message news:dfnfsc$tg6$1@digitaldaemon.com...
>>>> Walter thank you for doing the Bugs/4750 fix, but I think it's
>>>> still a bit broken. Because, if a negative value compares
>>>> again ulong.min it still gives the wrong result as the example
>>>> code below shows.
<snip>
> The trouble with such rules is they've become deeply embedded in the
> C/C++ programmer's psyche. The difference in behavior shows up in
> the corner cases. This means that if one relies on one's tried and
> true instincts about how things work, they'll fail oddly. Worse, it
> would make it impractical to convert existing C/C++ code to D that
> had non-trivial integer calculations in it.

The real question is: which is the lessest of three evils?

(a) admitting code that behaves differently from the same code in C (already done in at least two places)

(b) admitting code that has counter-intuitive behaviour

(c) the working cases that don't rely on this difference and would become bloated if we disallowed it, hence requiring a cast?

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS-
PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on
the 'group where everyone may benefit.

In article <dfri1g$1fgr$1@digitaldaemon.com>, Stewart Gordon says...
>
>Walter Bright wrote:
>> "Derek Parnell" <derek@psych.ward> wrote in message news:1sxotcg1idyvy$.1n1zgkwiqw7xg$.dlg@40tude.net...
>>> On Thu, 8 Sep 2005 19:25:01 -0700, Walter Bright wrote:
>>> 
>>>> "David L. Davis" <SpottedTiger@yahoo.com> wrote in message news:dfnfsc$tg6$1@digitaldaemon.com...
>>>>> Walter thank you for doing the Bugs/4750 fix, but I think it's still a bit broken. Because, if a negative value compares again ulong.min it still gives the wrong result as the example code below shows.
><snip>
>> The trouble with such rules is they've become deeply embedded in the C/C++ programmer's psyche. The difference in behavior shows up in the corner cases. This means that if one relies on one's tried and true instincts about how things work, they'll fail oddly. Worse, it would make it impractical to convert existing C/C++ code to D that had non-trivial integer calculations in it.
>
>The real question is: which is the lessest of three evils?
>
>(a) admitting code that behaves differently from the same code in C (already done in at least two places)
>
>(b) admitting code that has counter-intuitive behaviour
>
>(c) the working cases that don't rely on this difference and would become bloated if we disallowed it, hence requiring a cast?
>
>Stewart.
>

The three evils...what is a Monkey to do?
-----------------------------------------
a) Monkey see  (ignore it, move on to b)
b) Monkey hear (ignore it, move on to c)
c) Monkey do   (always cast to the highest type before a numeric compare)

Well I guess it's better for a Monkey to have a "cast," than a "wrench."

<g>

David L.

P.S. Stewart, I hope you don't mind me having a little fun with the three evils?


-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"
-------------------------------------------------------------------

MKoD: http://spottedtiger.tripod.com/D_Language/D_Main_XP.html

In article <dfri1g$1fgr$1@digitaldaemon.com>, Stewart Gordon says...
>
>Walter Bright wrote:
>> "Derek Parnell" <derek@psych.ward> wrote in message news:1sxotcg1idyvy$.1n1zgkwiqw7xg$.dlg@40tude.net...
>>> On Thu, 8 Sep 2005 19:25:01 -0700, Walter Bright wrote:
>>> 
>>>> "David L. Davis" <SpottedTiger@yahoo.com> wrote in message news:dfnfsc$tg6$1@digitaldaemon.com...
>>>>> Walter thank you for doing the Bugs/4750 fix, but I think it's still a bit broken. Because, if a negative value compares again ulong.min it still gives the wrong result as the example code below shows.
><snip>
>> The trouble with such rules is they've become deeply embedded in the C/C++ programmer's psyche. The difference in behavior shows up in the corner cases. This means that if one relies on one's tried and true instincts about how things work, they'll fail oddly. Worse, it would make it impractical to convert existing C/C++ code to D that had non-trivial integer calculations in it.
>
>The real question is: which is the lessest of three evils?
>
>(a) admitting code that behaves differently from the same code in C (already done in at least two places)
>
>(b) admitting code that has counter-intuitive behaviour
>
>(c) the working cases that don't rely on this difference and would become bloated if we disallowed it, hence requiring a cast?

All good points.  Although I'm leaning toward (c) (I take this as flag a compile
error since its ambiguous) I would argure for (d) - It doesn't matter (no
offense intended here).

No matter what, its going to be inconsistent with *something*; as you mention, they're all less than optimal (evil).  As long as the behavior is well-documented, possibly in a FAQ or something else more searchable, then at least it won't cause a programmer too much trouble.

I can't tell you how many times I've lost time to a problem that was built-in or a consequence of platform design that simply wasn't on the books.  Being able to look something like this up is what saves folks huge amounts of time, no matter what the decided outcome is.


- EricAnderton at yahoo

In article <dfri1g$1fgr$1@digitaldaemon.com>, Stewart Gordon says...
>
>The real question is: which is the lessest of three evils?
>
>(a) admitting code that behaves differently from the same code in C (already done in at least two places)
>
>(b) admitting code that has counter-intuitive behaviour
>
>(c) the working cases that don't rely on this difference and would become bloated if we disallowed it, hence requiring a cast?

Visual C++ flags comparisons between signed/unsigned types at warning level 4. Being a tad pragmatic, I always compile at this warning level and explicitly cast for the few comparisons where I want to allow this.  I would be willing to accept implicit comparisons of this nature being an error in D.  Porting C/C++ code would then be simple (if a bit tedious)--throw in a bunch of casts and you're done.


Sean