Re: [PATCH libgpg-error] Add support for IBM z/OS
Jacob Bachmeyer via Gnupg-devel <[email protected]>
| Newsgroups | gmane.comp.encryption.gpg.devel |
|---|---|
| Message-ID | <[email protected]> |
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 _______________________________________________ Gnupg-devel mailing list [email protected] https://lists.gnupg.org/mailman/listinfo/gnupg-devel