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()));
leading to compile errors like:
spawn-posix.c:66:10: error: field '__EnvnA' declared as a function
66 | char **environ;
| ^
/c390/archive/zosv2r4/S2441/util/usr/include/stdlib.h:885:29: note: expanded
from macro 'environ'
885 | #define environ (*(__EnvnA()))
| ^
spawn-posix.c:421:12: error: expected identifier
421 | if (act->environ)
| ^
/c390/archive/zosv2r4/S2441/util/usr/include/stdlib.h:885:26: note: expanded
from macro 'environ'
885 | #define environ (*(__EnvnA()))
| ^
spawn-posix.c:422:48: error: expected identifier
422 | execve (pgmname, (char *const *)argv, act->environ);
| ^
/c390/archive/zosv2r4/S2441/util/usr/include/stdlib.h:885:26: note: expanded
from macro 'environ'
885 | #define environ (*(__EnvnA()))
| ^
spawn-posix.c:523:8: error: expected identifier
523 | act->environ = environ_for_child;
| ^
/c390/archive/zosv2r4/S2441/util/usr/include/stdlib.h:885:26: note: expanded
from macro 'environ'
885 | #define environ (*(__EnvnA()))
| ^
4 errors generated.
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.
Let me know if you'd prefer an alternative approach.
Regards
Sachin
From: Jacob Bachmeyer <jcb62...@gmail.com>
Date: Wednesday, 11 June 2025 at 8:13 AM
To: Sachin T <sachi...@ibm.com>, gnupg-devel@gnupg.org <gnupg-devel@gnupg.org>
Subject: [EXTERNAL] Re: [PATCH libgpg-error] Add support for IBM z/OS
On 6/10/25 10: 15, Sachin T via Gnupg-devel wrote: [. . . ] 3. On z/OS, environ
is defined as a macro in <stdlib. h>, so it is temporarily redefined around the
header inclusion to avoid conflicts. [. . . ] diff --git a/src/spawn-posix. c
b/src/spawn-posix. c
On 6/10/25 10:15, Sachin T via Gnupg-devel wrote:
[...]
3. On z/OS, environ is defined as a macro in <stdlib.h>, so it is temporarily
redefined around the header inclusion to avoid conflicts.
[...]
diff --git a/src/spawn-posix.c b/src/spawn-posix.c
index ac19761..2666862 100644
--- a/src/spawn-posix.c
+++ b/src/spawn-posix.c
@@ -27,8 +27,17 @@
#error This code is only used on POSIX
#endif
+#if defined(__MVS__)
+#define environ environ_replace
+#endif
+
#include <stdio.h>
#include <stdlib.h>
+
+#if defined(__MVS__)
+#undef environ
+#endif
+
#include <stdint.h>
#include <string.h>
#include <errno.h>
What exactly is this dance supposed to do? The C preprocessor has no
equivalent to M4's pushdef()/popdef().
If environ is supposed to be a symbol, then there is no reason to define it
before including stdlib.h and undefining it to get rid of the macro. If the
file does not use environ, then why care? If environ's macro definition is
actually important on z/OS, then this dance likely causes breakage.
What is this trying to accomplish?
-- Jacob
_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-devel
