On 19-Dec-2013 10:02 -0800, Hiebert, Chris wrote:
<<SNIP>>
tested again using the "*1" parm.
Again, the user space was auto-extended and the data was returned.
Having verified that forcing the RPG to /respect/ the CONST by
ensuring a temporary-copy of the variable would occur, per the
specification of the expression DSPF0100.BytesAvail*1 versus just the
variable DSPF0100.BytesAvail, seems to confirm the suspicion that the
RPG compiler was the origin for the changed behavior.
The other results seen, and my test on v5r3, seem to suggest that API
is unchanged. At some point in its processing, the API is apparently
referencing the since-corrupted memory for its second argument, when
making a decision about what\how-much data is getting written to the
receiver variable; i.e. deciding to write no data, other than
BytesAvailable and BytesReturned.
I find it strange that the location of the input variable would
matter to the QDFRTVFD API for a parameter that the API defines as
input.
As I alluded, it is far from ideal for the API to be coded that way,
although that effect by itself, probably is not a valid /defect/; i.e.
being undocumented, the effect should be considered undefined and
unpredictable, and that would likely be the response from dev... though
they might /fix/ the issue in a future release anyhow if reported. It
is my experience as a /de facto/ expectation, that with any code
interface [built-in, API, etc.] the same memory location used for
/output/ should not be utilized to provide /input/ *except* when there
is explicit documentation stating that doing so is allowed or otherwise
the docs clearly describes the expected outcome.
What seems to me to be an obvious defect in this scenario however,
and what I presume would be corrected simply by the API implementing a
change to enable the same memory location to be used safely for both the
input and output parameters, is that the API claims to have returned the
data, yet no data was returned. IMO, there clearly is something wrong
with that effect [the API telling the invoker that all of the data was
returned when in fact none was], irrespective its origin; i.e. if the
API returns only eight bytes of valid return information, then the API
should tell the invoker that only eight bytes were returned, and if the
API tells the invoker that all of the data was returned, then the data
in the receiver variable should be there.
Of course the onus is on the invoker to review\test how much data the
API has passed back, such that if the API properly tells the invoker
that only eight bytes were returned, then the caller must avoid looking
at the structures at offsets\positions beyond those bytes returned.
While the first invocation /should/ probably be indicative, the correct
values could be different for some reason; most legitimately if the
Display File had since been replaced.
I think I'll have a PMR opened with IBM to make sure this is the
intended operation of the API.
I think that is most appropriate. And while a /correction/ to the
API would solve the issue without any code changes to the code that
invokes the API [although I infer such changes have already been made],
I still would avoid coding that way; i.e. I would explicitly avoid using
the memory location of the output as input to the API, by using a local
variable. I would not code the the parameter as an expression either,
as an effective /trick/, to make the RPG create the temporary copy from
the memory shared with the receiver variable.
midrange.com
