Re: Need an RPG pgm that returns Days Until Password Expires

Agreed, but I didn't want to give the answer away by saying "in an error
situation".

This sample will actually corrupt storage in the "non-error" situation. If
an API "sees" a Bytes Provided value greater than 8 (which qualifies with
this example) then the storage address four bytes beyond the address of the
"blank" is going to be updated to x'00000000' (Bytes Available) when no
error in the API call is detected. So storage is corrupted simply by calling
the API as demonstrated in the example. Assuming the temporaries RPG sets
aside for consts are 16-byte aligned then this corruption would go
undetected (for now and assuming RPG isn't using the other 15 bytes for
"something", which I doubt).

In an error situation the corruption could certainly be visible even today.

On Wed, Dec 23, 2009 at 10:42 AM, Barbara Morris <bmorris@xxxxxxxxxx> wrote:

Bruce Vining wrote:

Pop quiz to those of you familiar with system APIs. Can you find where

four

bytes of storage are corrupted by this simple example? (I will admit that
due to current implementation of the RPG compiler this corruption will

most

likely go undetected at run-time, but a compiler implementation change in
the future could toast any program using this example as a model for

calling

sysem APIs -- corruption is corruption)

Good catch!

I think it could quite easily lead to detectable corruption at runtime
already, and I don't think it would be limited to only 4 bytes.

The prototype for the error code parameter is 1a const, and a blank is
being passed. The compiler will create a 1-byte temporary and set it to
blank (x'40') and pass the address. No matter what the following 3
bytes contains, the API will find that the bytes-provided subfield of
the error code is at least x'40000000' (1073741824), and will be free to
update that much storage starting at the 1-byte temporary.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.