× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Instead of having a warning (which, IMHO, is a total waste of time... both my time, and IBM's) I would suggest a new D-spec keyword: EXACT.

The idea would be that the caller must provide a variable that's identical to the one on the prototype. Even if CONST or VALUE was supplied, it still has to be exact.

That assumes that we actually care enough about this problem to try to solve it. (Which, I don't.)


On 5/18/2010 12:27 PM, Vern Hamberg wrote:
Scott

To add to what you said, it seems to me that using CONST or VALUE, which
all the use of an expression instead of requiring a variable to be
passed, open up just what you have described. Even a single variable is
perhaps considered an "expression" on parameters so marked. It WOULD
still be possible to know that a 9,0 packed variable *could* overflow a
9,2 packed parameter, and this might merit a warning. But other
expressions - well, again, where does it all stop? At the feet of the
developer, as you said.

This does make me think, also, that perhaps having a prototype or
parameter definition fairly distant in source from usage, could lend
itself to not remembering what the definition is. But, again, developer
needs to check these things.

JMNSHO
Vern

Scott Klement wrote:
Hi Bryce,

On 5/18/2010 7:55 AM, Bryce Martin wrote:

Why wouldn't you want the compiler to catch as many things as possible?


I'm not sure you understand the ramifications of what you're asking for.
You, seriously, want a warning every single time a field _can_ overflow?

I agree that, when it's obvious that the field _will_ overflow, it'd be
nice if the compiler warned you. For example something like this:

D x s 3p 0
x = 99999999;

There's no way that 99999999 can fit in a 3,0 field. It'll never
happen, so this code will always blow up. It might be nice if the
compiler warned you of this -- but on the other hand, shouldn't this be
obvious to the programmer?

But I sure don't want a warning any time a field _can_ overflow.
There'd be so many warnings I'd go crazy. For example, this:

count = count + 1;

It doesn't matter what 'count' is defined as, this statement has the
chance of overflowing since if count is already at it's maximum value,
this would overflow. Do you really want the compiler to send you a
warning every single time you accumulate anything?

total = total + itemExtended;
-or-
totWeight = totWeight + (boxQty * wgtPerBox);

This would always generate an overflow warning! This type of logic is
completely ubiquitous in business programming. You'd be getting
overflows everywhere.

Seems like a gross overreaction to the original problem. (Which frankly,
was purely a matter of inexperience on the part of the O.P.)



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.