Re: Parameter prototype question

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