[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