Re: z/OS and symlink()

[Daniel Richard G.]

Hi Bruno,

On Tue, 2017 Feb 28 16:47+0100, Bruno Haible wrote:
> 
> 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. ...
> 
> > 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


-- 
Daniel Richard G. || address@hidden
My ASCII-art .sig got a bad case of Times New Roman.