z/OS and symlink()

[Daniel Richard G.]

Currently, test-symlink and test-symlinkat are failing on z/OS:

$ ./test-symlink
.../test-symlink.h:64: assertion 'errno == ENOTDIR || errno == ENOENT' failed
CEE5207E The signal SIGABRT was received.
ABORT instruction

$ ./test-symlinkat
.../test-symlink.h:64: assertion 'errno == ENOTDIR || errno == ENOENT' failed
CEE5207E The signal SIGABRT was received.
ABORT instruction

What happens in both cases is that errno == EINVAL. If I add that to the
ASSERT() condition at lines 63 and 84 of test-symlink.h (as of a3fd683d),
then these two tests pass.

IBM documents EINVAL as a possible return value for symlink():

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r1.bpxb100/sym.htm

(symlinkat() does not appear to exist on this platform.)

However, the GNU/Linux man pages for symlink() and symlinkat() make no
mention of EINVAL. I don't know if this is a reasonable platform
variation, or a technical violation of POSIX. (If the latter, then I can
push this to IBM and they'll at least take it seriously.)


Please advise,


--Daniel

[Bruno Haible]

Post by Daniel Richard G.
$ ./test-symlink
.../test-symlink.h:64: assertion 'errno == ENOTDIR || errno == ENOENT' failed
CEE5207E The signal SIGABRT was received.
ABORT instruction
$ ./test-symlinkat
.../test-symlink.h:64: assertion 'errno == ENOTDIR || errno == ENOENT' failed
CEE5207E The signal SIGABRT was received.
ABORT instruction
What happens in both cases is that errno == EINVAL. If I add that to the
ASSERT() condition at lines 63 and 84 of test-symlink.h (as of a3fd683d),
then these two tests pass.
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r1.bpxb100/sym.htm

The relevant spec here is POSIX:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/symlink.html
Line 64 of test-symlink.h:64 corresponds to the case

[ENOENT] or [ENOTDIR]
The path2 argument contains at least one non- <slash> character and ends with one or more trailing <slash> characters. ...

Post by Daniel Richard G.
However, the GNU/Linux man pages for symlink() and symlinkat() make no
mention of EINVAL.

When a facility is specified by POSIX, gnulib's tests try to go with the POSIX
spec, at least on non-glibc platforms.

Bruno

[Daniel Richard G.]

Post by Bruno Haible
http://pubs.opengroup.org/onlinepubs/9699919799/functions/symlink.html
Line 64 of test-symlink.h:64 corresponds to the case
[ENOENT] or [ENOTDIR]
The path2 argument contains at least one non- <slash> character
and ends with one or more trailing <slash> characters. ...

Post by Daniel Richard G.
However, the GNU/Linux man pages for symlink() and symlinkat() make
no mention of EINVAL.

When a facility is specified by POSIX, gnulib's tests try to go with
the POSIX spec, at least on non-glibc platforms.

All right, that document seems pretty cut-and-dry about what
errno values can be returned. I'll file a report with IBM and see
what they say.


Thanks for the pointer,


--Daniel

[Daniel Richard G.]

Hi Bruno,

Post by Bruno Haible
http://pubs.opengroup.org/onlinepubs/9699919799/functions/symlink.html
Line 64 of test-symlink.h:64 corresponds to the case
[ENOENT] or [ENOTDIR]
The path2 argument contains at least one non- <slash> character
and ends with one or more trailing <slash> characters. ...

Post by Daniel Richard G.
However, the GNU/Linux man pages for symlink() and symlinkat() make
no mention of EINVAL.

When a facility is specified by POSIX, gnulib's tests try to go with
the POSIX spec, at least on non-glibc platforms.

This is IBM's response (cleared for public posting):

The POSIX reference to which you referred is The Open Group Base
Specifications Issue 7 IEEE Std 1003.1-2008, 2016 Edition. Our
product is branded upon the following standard (UNIX95), per our
z/OS UNIX System Services Planning Guide:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This document presents the information you need to plan for and run
an IBM z/OS system with support for z/OS UNIX System Services (z/OS
UNIX). This element and the Language Environment element and z/OS
XL C/C++ compiler provide an application programming interface
(API) and a shell interface based on the open systems standards of
the Institute of Electrical and Electronics Engineers (IEEE)
Portable Operating System Interface (POSIX) project, the Federal
Information Processing Standard (FIPS), and the X/Open Portability
Guide Issue 4 (XPG4).
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

[As] our implemented (older) version of the POSIX standard, the
following line from the new standard did not yet exist:

[ENOENT] or [ENOTDIR]
The path2 argument contains at least one non-character and ends
with one or more trailing characters. If path2 without the
trailing characters would name an existing file, an [ENOENT] error
shall not occur.

Since the above did not exist in the POSIX standard from which we
are based, we implemented a return code (EINVAL) to handle such a
case. In general, a platform can implement return codes that do not
otherwise conflict with the standard as an "implementation
extension".


They went on to say that we could make an RFE to support the newer rev
of POSIX, but realistically, that will sit in their queue for years.

Special-case the test for z/OS?


--Daniel

[Paul Eggert]

Post by Daniel Richard G.
Special-case the test for z/OS?

That sounds like the right way to go, yes. I hope the special case is
small and unobtrusive code.