bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / Atom feed
From: Igor Todorovski <itodorov@ca.ibm.com>
To: "bug-gnulib@gnu.org" <bug-gnulib@gnu.org>,
	Mike Fulton <fultonm@ca.ibm.com>
Subject: Z/OS Enhancement to gnu lib
Date: Mon, 30 Jan 2023 04:09:45 +0000	[thread overview]
Message-ID: <BN7PR15MB2466749C86F0FD8E23E7D0F0EDD39@BN7PR15MB2466.namprd15.prod.outlook.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1924 bytes --]

Hi,

I was wondering if the following changes I made to findutils (to get it to function on z/OS) can be merged into gnulib.

The first change (fdopendir.c) guards the close call. Otherwise we get a bad file descriptor on z/OS. I am not sure if this has any other consequences, but so far I haven’t seen any issues with findutils.

The second change (openat-proc.c) adds a way to get the pathname when given a file descriptor as an input.

If you have any comments, please let me know:

index c2b0e1e..82ae2e4 100644
--- a/gl/lib/fdopendir.c
+++ b/gl/lib/fdopendir.c
@@ -151,7 +151,9 @@ fdopendir_with_dup (int fd, int older_dupfd, struct saved_cwd const *cwd)
         }
       else
         {
+#ifndef __MVS__
           close (fd);
+#endif
           dir = fd_clone_opendir (dupfd, cwd);
           saved_errno = errno;
           if (! dir)
diff --git a/gl/lib/openat-proc.c b/gl/lib/openat-proc.c
index 3bacf7d..bb788fd 100644
--- a/gl/lib/openat-proc.c
+++ b/gl/lib/openat-proc.c
@@ -28,6 +28,7 @@
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
+#include <termios.h>
#include <unistd.h>
 #ifdef __KLIBC__
@@ -53,7 +54,27 @@ openat_proc_name (char buf[OPENAT_BUFFER_SIZE], int fd, char const *file)
       return buf;
     }
-#ifndef __KLIBC__
+#ifdef __MVS__
+  {
+    char dir[_XOPEN_PATH_MAX];
+    int rc = w_ioctl(fd, _IOCC_GPN, _XOPEN_PATH_MAX, dir);
+    if (rc == 0) {
+      __e2a_l(dir, _XOPEN_PATH_MAX);
+    }
+    size_t bufsize;
+    dirlen = strlen (dir);
+    bufsize = dirlen + 1 + strlen (file) + 1; /* 1 for '/', 1 for null */
+    if (OPENAT_BUFFER_SIZE < bufsize)
+      {
+        result = malloc (bufsize);
+        if (! result)
+          return NULL;
+      }
+
+    strcpy (result, dir);
+    result[dirlen++] = '/';
+  }
+#elif !defined( __KLIBC__)
# define PROC_SELF_FD_FORMAT "/proc/self/fd/%d/"
   {
     enum {


[-- Attachment #2: Type: text/html, Size: 14454 bytes --]

             reply	other threads:[~2023-01-30  7:14 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-30  4:09 Igor Todorovski [this message]
2023-01-30 11:48 ` Z/OS Enhancement to gnu lib Bruno Haible
2023-01-30 17:29   ` Igor Todorovski
2023-01-30 22:12     ` Bruno Haible

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BN7PR15MB2466749C86F0FD8E23E7D0F0EDD39@BN7PR15MB2466.namprd15.prod.outlook.com \
    --to=itodorov@ca.ibm.com \
    --cc=bug-gnulib@gnu.org \
    --cc=fultonm@ca.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).