Workaround for uintptr_t on IBM i?

[nickaudinet]

We are upgrading from openssl 3.0.18 to 3.5.4 on IBM i 7.5. I have the new version mostly building, however I'm not sure what to do about the usage of uintptr_t and intptr_t in the codebase. These types do not exist on IBM i, because pointers there are 16 bytes and the largest integer type is 8 bytes (and casting between pointers and ints is not encouraged either). I already saw this issue: #22002, but the solution there is specific to nonstop.

I guess IBM i is not offically supported or anything, so really I'm just trying to get some advice on my options here. I've seen some places in the code where I can replace the parts that use uintptr with something else, but other places look like I'd have to rewrite substantial portions to not use it. Would replacing it myself be as bad as it sounds?

I'm also not an expert on IBM i, I only dabble in it occasionally. If someone knows a workaround for uintptr that would be good too (I didn't find anything online though). I'm also looking into maybe using PASE and gcc to compile it, but I don't know if I could link the resulting libraries to our application it I do that.

Any help is appreciated!

[nhorman]

According to https://www.ibm.com/docs/en/aix/7.1.0?topic=files-inttypesh-file

AIX 7.1 forward should include a definition of uintptr_t. Are you working with an older version of AIX perhaps?

Also (bearing in mind I know nothing about i-series space pointers), It seems strange to me that we would be using pointers that fall outside of the usual 8 byte address size. From what I read those pointers need to be declared specially with various #pragmas.

In either case, I would do the following:

1. Write a test program to check sizeof(void *), and confirm that the pointer is truly 16 bytes wide
2. if (1) is false, and you just don't have a uintptr_t defined, you can define it by hand, similar to what we do for UEFI in e_os2.h, like:

typedef uint64_t uintptr_t

assuming the pointers are truly 8 bytes wide, not 16
3) If you are in fact somehow working with 16 byte pointers, I suppose you could still do (2), like this:

typedef uint64_t[2] uintptr_t

or some such, but I can't guarantee that such pointers are castable, giving the upper 8 bytes holds security and typing information.

I'd also note that the use of uintptr_t has been present on ppc builds (which I assume is covered by i-series), and has been in place since openssl 1.1.1 (see commit 8c8fbca), so I would suggest that you look for header definitions of uintptr_t first as it seems you would have encountered this previously, if uintptr_t really didn't exist (it may be that its definition is in a non-standard location, and we just don't have the right includes for that arch).

[nickaudinet]

Thanks for the reply

I have checked the sizeof(void*), and it is indeed 16 bytes. AIX is another platform we use, and openssl builds fine there. But IBM i is its own can of worms. I know the "PASE for i" environment is basically AIX on IBM i, and if its possible to link code built in PASE to a 'native' IBM i program, then this wouldn't be an issue. But I'm not an expert so I have no idea if this is possible (my gut feeling is it's not).

I saw in our current 3.0.18 version that there are references to uintptr_t, but they are in places that are not compiled for our IBM i builds. For example its used in crypto/dso/dso_dlfcn.c, but its guarded by an #ifdef _AIX. Its also used in crypto/poly1305/poly1305_ppc.c which is not compiled in our IBM i builds (I haven't looked into why exactly).

I will look further into option 3.

[nhorman]

Ok, so you're actually using the i operating system with the AIX bindings, not AIX proper. From what I'm reading, yes, you're going to have to typedef uintptr_t yourself to some 128 bit storage. FWIW, The Z/OS docs do indicate that a __uint128_t type exists which would allow for the cast without loss of information, but I have no idea if that will work properly.

[monnerat]

In ILE environment, this is impossible for a user program to build a 128-bit pointer from an integer alone, because there is a read-only 129th bit somewhere in the system that tells whether a 16-byte paragraph contains a valid pointer or not.

Valid 128-bit pointers are opaque structured values that may only be obtained as the result of a computation from another valid pointer or from the system. There is no operation usable from a user mode program to convert an integer alone to a 128-bit pointer, even if some 128-bit integer type existed. Forging the pointer would'nt work either because this clears the valid flag bit.

You then can't implement uintptr_t as defined in the standards and probably IBM never will. You can however emulate it using char * for uintptr_t (this will retain +/- arithmetics on it) as an approximation, providing conversions from/to it are properly casted: there is no miracle here and if the operations on it are too "integer-oriented" (i.e.: like modulus for alignment), that won't work.

Another solution is using TERASPACE pointers (monotonic 64-bit pointers), but they won't be able to address objects outside of TERASPACE. In addition, not all languages support TERASPACE easily. You can always convert a TERASPACE pointer into a 128-pointer, but a 128-bit pointer can be converted to a 64-bit pointer only if it points to a TERASPACE object.