Re: Parameter prototype question

[Rory Hewitt <rory.hewitt@xxxxxxxxx>]

David,

Consider this scenario: You have a 5P 0 parameter defined for a procedure.
That means it can take any value up to 99999.

Should you be allowed to call that procedure passing a 10P 0 field, even
though the *value* in the field is always less than 100000 (i.e. it's 5
digits)?

If you have CONST specified, this compiles and works fine. It will always
work fine, *unless* you pass a larger value in the 10P 0 field than 99999.
But in that case, it really is *your job* to know what is the largest value
that your procedure can accept.

However, if you *don't* have CONST specified, you always have to move the
value from the 10P 0 field into a 5P 0  work field to pass it to the
procedure. Since that process (before you've even called the procedure) will
stop you from passing a value that's > 99999, then the procedure call itself
will never fail. But you always have to pass a 5P 0 field to the procedure,
which is an extra step in your calling code.

The key statement above is this: "If you have CONST specified [...] it
really is your job to know what is the largest value that your procedure can
accept.". Essentially, specifying CONST removes *some* compile-time
checking, which can make life much easier and more flexible, but at a slight
increase in risk. Your choice to use CONST implies that you will check your
code more thoroughly, to make up for what the compiler will not do for you.

Rory

On Fri, May 14, 2010 at 7:30 AM, David FOXWELL <David.FOXWELL@xxxxxxxxx>wrote:

> I don't need to consider the reverse situation here. Its just a simple case
> as with most of our procedure calls of wanting to pass a variable from one
> procedure to another and wanting the compiler to check that for me. If
> you're saying that I should have checke the attributs of each of the 20 or
> so parameters myself then what's the point of having a compiler that is
> capable of checking?