[PATCH libgpg-error] Add support for IBM z/OS

Jacob Bachmeyer jcb62281 at gmail.com
Fri Jun 13 05:46:30 CEST 2025


On 6/12/25 09:22, Sachin T wrote:
>
> Hi Jacob,
>
> Thanks for the feedback. I’d like to clarify  the change.
>
> On z/OS, environ is defined as a macro in <stdlib.h>:
>
> #define environ (*(__EnvnA()))
>
> This causes any use of environ in user code — even inside structs or 
> function parameters  to be macro-expanded in invalid ways. For 
> example, the following line in spawn-posix.c:
>
> char **environ gets rewritten by the preprocessor as: char 
> **(*(__EnvnA()));
>
> act->environ gets rewritten by the preprocessor as: act->(*(__EnvnA()));
>
> [...]
>
> To resolve this, we temporarily redefine environ around the inclusion 
> of the header files that use it. This allows the code to compile 
> without macro expansion issues.
>
That does not work like that in C.  The preprocessor does not process 
macro expansions prior to evaluating a #define.

The only part from that part of your patch that actually has effect is:

#if defined(__MVS__)
#undef environ
#endif

If macro-expanding environ causes problems elsewhere in the code, I see 
two options:

(1) Avoid using the token 'environ' except as the process global 
environment pointer.  (Perhaps we could rename the 'environ' field in 
whatever structure 'act' refers to to 'env'?)

(2) Add:

#ifdef environ
#undef environ
#endif

after including <stdlib.h>.  This would also handle other systems that 
define 'environ' as a macro, provided that no access to the process 
global environment is actually needed, since it would make environ 
inaccessible if a macro expansion is required.


-- Jacob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250612/653ff7f5/attachment.html>


More information about the Gnupg-devel mailing list