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
