Re: Procedure parameter with VALUE option

["Peter Dow" <pcdow@xxxxxxxxx>]

Hi Barbara,

Thanks, that's what I needed -- question my assumptions!  The prototypes
were coming from different copy members.  Once I fixed that, everything was
as expected.

Although I'm still curious -- does VALUE conversion include size as well as
type?  If I'm passing 128 bytes (not varying) to a 32K parameter (also not
varying), will it place 32K on the stack (the 128 bytes + blanks)?

In the following procedure, I'm thinking I can reduce the amount of copying
(which as Scott Klement points out is, even if cheap, still more expensive
than simply
passing a pointer) by using the following:

p IFS_prt         b                   export

d IFS_prt         pi
d  hFile                              like(int) value
d  Text                      32766a   const varying

d Data            s          32766a   varying
d NbrWritten      s                   like(int)

c                   eval      Data = Text
c                   eval      NbrWritten = api_write(
c                                          hFile:
c                                          %addr(Data) + 2:
c                                          %len(Data))

p                 e

Note the "+ 2" to skip the embedded length.  Will this get me in trouble in
the future?  Is it possible IBM will decide to increase the length to 4
bytes?

tia,
Peter Dow
Dow Software Services, Inc.
909 425-0194 voice
909 425-0196 fax



----- Original Message -----
From: <bmorris@ca.ibm.com>
Sent: Friday, December 14, 2001 9:08 AM
Subject: Re: Procedure parameter with VALUE option
> Peter, conversion is done if necessary.  The value is put on the stack as
> dictated by the parameter's type in the prototype.  It's convenient to
> think of the compiler having a temporary of the prototype-type, and
> EVALing the passed parameter to this temporary, then copying the temporary
> to the parameter stack.  (A temporary may or may not be involved - some
> conversions can be done "on the stack", but the effect is the same.)
>
> I can't explain your debug session output.  Are you sure sure sure that
> those are the correct prototypes?

<snip>

> There are many ways to handle character parameters.  My personal
> recommendation is CONST VARYING.  Passing large VALUE parameters
> is always a bad idea (every language, every system).  If you
> need to modify the parameter within the procedure, but the
> caller doesn't need to see the change, declare a temporary and
> copy the passed parameter to the temp.  Copying is cheap.



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com