× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi Michael,

The problem is with parameter 2 on the call to _prop_stack_pop. The
argument that is passed is '&obj1', which is the address of an 8-byte void
pointer. The address-of operator always produces an 8-byte pointer under
the teraspace storage model, so '&obj1' is an 8-byte pointer to an 8-byte
pointer to void (void * __ptr64 * __ptr64). The second parameter of
_prop_stack_pop is declared to be a 'prop_object_t *', or 8-byte pointer to
prop_object_t, which is a 16-byte pointer to void (for a resulting type of
void * __ptr128 * __ptr64). Automatic address conversion cannot be used to
convert these values because only the top level pointer is converted
automatically, and the difference is in the type pointed to by the top
level pointer. You will need to change your code to provide the address of
a 16-byte pointer value as the second argument to the _prop_stack_pop
function.

Thanks,

Aaron Albertson


c400-l-bounces+albertaa=us.ibm.com@xxxxxxxxxxxx wrote on 06/05/2010
01:10:29 AM:

[image removed]

Re: [C400-L] pointers in different storage models

Schmidt, Mihael

to:

C programming iSeries/AS400

06/05/2010 01:12 AM

Sent by:

c400-l-bounces+albertaa=us.ibm.com@xxxxxxxxxxxx

Please respond to C programming iSeries / AS400

Thanx. Yes that helped a lot. Though I don't want mess that much
with the source.

After some tries it actually worked even in an RPG program. Great.

Though after I changed some other code to __ptr128 I got the following
error:

prop_object.c, 1106.46: CZM0280(30) Function argument assignment between
types "void* __ptr128* __ptr64" and "void* __ptr64* __ptr64" is not
allowed.


typedef void * __ptr128 prop_object_t;

bool
prop_object_equals_with_error(prop_object_t obj1_128, prop_object_t
obj2_128,
bool *error_flag)
{
void * obj1, obj2;
obj1 = obj1_128;
obj2 = obj2_128;
...


line 1106: if (!_prop_stack_pop(&stack, &obj1, &obj2,
&stored_pointer1, &stored_pointer2))



bool _prop_stack_pop(prop_stack_t, prop_object_t *, void ** , void
**, void **);


My guess is that it is the third parameter on the call to pop() put
I don't know enough about C to know why this happened and how it can
be fixed. My understanding is that obj1 and obj2 are 64 bit
pointers. So why the error message with 128 bit pointer?

Thanx in advance

Mihael



-----Original Message-----
From: c400-l-bounces+mihael.schmidt=rossmann.de@xxxxxxxxxxxx [
mailto:c400-l-bounces+mihael.schmidt=rossmann.de@xxxxxxxxxxxx] On
Behalf Of Mark S. Waterbury
Sent: Saturday, June 05, 2010 12:36 AM
To: C programming iSeries / AS400
Subject: Re: [C400-L] pointers in different storage models

Hi, Mihael:

I think rather than creating a whole new "layer" or "wrapper" around
your service program, if you have the source for the *MODULEs comprising
the service program, you could just change the "interfaces" to the
exported procedures and functions so they use 128-bit pointers, e.g.
using the special __ptr128 keyword:

char * __ptr128 p;

Then, within your procedures, the first thing you do is copy the
parameter pointer to a local variable that is a 64-bit pointer, then use
only 64-bit pointers inside the C or C++ code, which is more efficient.
Then, if you need to return a pointer, convert that from a 64-bit
pointer to a 128-bit pointer just before the return.

Does that make sense?

In other words, you don't need a whole extra layer. If your intention
is that this *SRVPGM procedures are callable from any other ILE
language, all parameters should be 128-bit pointers, because I don't
think any other ILE HLL languages besides C and C++ currently support
64-bit pointers.

Does that help?

Mark S. Waterbury

> On 6/4/2010 5:16 PM, Schmidt, Mihael wrote:
Oh. I think I missed something. Pointer conversion will
automatically take place for C and C++ programs. Does the RPG
compiler / runtime automatically convert pointers? If I take the
result of my program my guess is that it doesn't.

Is the solution to build a C wrapper service program for the
"real" service program which contains a wrapper procedure for every
procedure containing pointer as return values or parameters, so that
they will be converted from 16 byte to 8 byte and vice versa?

Mihael

--
This is the C programming iSeries / AS400 (C400-L) mailing list
To post a message email: C400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/c400-l.

--
This is the C programming iSeries / AS400 (C400-L) mailing list
To post a message email: C400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/c400-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.