Re: Parameter prototype question

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.)