Re: Playing with pointers, use of realloc questions.

Don't know if you have moved on from this but any solution that requires
pointer for users, even programmers is most likely a poor solution. In your
case, that is being compounded by your expectation that the user creates a
structure of some kind and passes you a pointer to it. Now you are exposing
your internal structures to users.

The problem that I hear in your discussion is that your solution sounds
very OPM (Original Program Model) rather than ILE.

As you know OPM solutions to problems came about because the only mechanism
for externalizing logic was program call which was very slow so people
built applications (IBM API's for example) where the user passes all kinds
of parameters and multiple buffers and then the programmer has to try to
decode data being returned with things like records inside of records.

So what I hear you saying is that you are receiving arrays of data and your
users are required to build the structures for you there are all kinds of
problems which you have already identified.

The solution is to use ILE. The advantage that have with service programs
is that you have multiple points to entry (Procedures) and that they are
extremely fast. In the time it takes you to make one program call you can
execute 10 of thousands of procedure calls. That means we can break things
down into small pieces and hide details. You still need pointers but they
are inside of your service program.

So the scenario becomes that you call a procedure in your service program
that builds data in your own internal structures based on dynamic memory.
You then have another procedure that can get a count of the number that you
have and another that returns one record or does a set and then getter
functions that get fields.

This can go the other way with you providing functions that allows the
programmer to send you records or setters that build a record and the a
function that issues the update.

All this is possible because ILE provides service programs with procedures
and high performance. What you want is to build small procedures performing
one function and only one function. I always say that you should be able to
describe what the function does without the use of a conjunctive verb
(And/Or). The advantage to using Getter and Setter is obvious. It doesn't
tie you into a specific format that returning a record would but more work.

Anyway just suggesting you use the power of ILE instead of pursuing an OPM
solution. Returning or receiving pointers is almost always a poor
solution.

On Wed, Aug 12, 2015 at 5:42 AM, Wilson, Jonathan <piercing_male@xxxxxxxxxxx

wrote:

I am currently playing with basing pointer usage to return multiple
formats of data from a service program.

The idea is that the called service program will handle all the data
access nicely wrapped up in procedures defined around the functional
description and not the data accessed.

For example, Status = GetBibliographicDataFirst(Data:'*KEYSONLY');

The "Data" passed both ways is a structure containing keys and a
variable length area to allow for data to be returned.

The second parameter denotes the data format to be returned, in this
simplified example it could be *NONE, *KEYSONLY, FMT001, or FMT002.

Now I have this all working using basing pointers in the function,
something along the lines of...

DataLayout00 (based p_inputData)
Keys.ISBN
Keys.SupplierNo
DataLayout01 (based p_inputData)
Keys.ISBN
Keys.SupplierNo
MTBIBLDS
DataLayout02 (based p_inputData)
Keys.ISBN
Keys.SupplerNo
MTBIBLDS
TitleDS
AuthorDS


// do file stuff with data passed in, setting IsFound to record status
select
where DataType = '*NONE' or p_inputData = *null
return IsFound
where DataType = '*KEYSONLY'
// Set keys of DS to keys of file.
return IsFound
where DataType = 'FMT001'
// Set keys of DS to keys of file.
// Set MTBIBLDS to RecordDS
return IsFound
where DataType = 'FMT002'
// Set keys of DS to keys of file
// Set MTBIBLDS to RecordDS
// Set TitleDS from title file
// Set AuthorDS from author file
return IsFound
endsl

So far so good, it all works as expected...

But, the caller is the one setting up the "Data" to be returned and as
such I have no control over if this field is long enough, even if I were
to have extra parameters with say the length of the "Data" there is
nothing stopping the caller lying and, as far as I know, there is no
programmable way of finding out the definition (or at least its length)
of the field in the caller that was actually passed.

Now to prevent the called service program from corrupting memory, I was
wondering if the use of the %realloc would be sensible way of guarding
against overwriting memory, in the called procedure I always perform a
realloc to set up the data to the desired length prior to setting up the
data. Something along the lines of...

where format type is..
p_inputData = %realloc(p_inputData:%size(DataLayout02))
// do stuff
// return status.
endsl

Now if the callers field was to small, it can't see the extra data
returned so no problems - actually its a different problem but one I can
live with as its not a silent corruption or an escape/MCH style function
check if program code is stomped on, or the inbuilt bounds checks
catches it.

Now I understand that the above, assuming it works, adds an overhead as
it has to allocate memory and copy the existing data to it and that its
possible that the realloc might fail.

But I am curious as to how others have dealt with this problem or done
something similar, or if prevented by just not doing multi-format data
passing.

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.