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

Sachin T sachin.t at ibm.com
Thu Jun 12 16:22:21 CEST 2025


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 <jcb62281 at gmail.com>
Date: Wednesday, 11 June 2025 at 8:13 AM
To: Sachin T <sachin.t at ibm.com>, gnupg-devel at gnupg.org <gnupg-devel at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20250612/eced4cd7/attachment-0001.html>


More information about the Gnupg-devel mailing list