realpath - Unix

This is a discussion on realpath - Unix ; hello comp.unix.programmer Does realpath() write PATH_MAX bytes including or excluding the zero byte? http://www.opengroup.org/onlinepubs/...399/functions/ realpath.html> Suggests PATH_MAX *with* the zero byte, but the example uses an array of PATH_MAX + 1 bytes....

+ Reply to Thread
Results 1 to 8 of 8

Thread: realpath

  1. realpath

    hello comp.unix.programmer

    Does realpath() write PATH_MAX bytes including or excluding the zero
    byte?
    <http://www.opengroup.org/onlinepubs/...399/functions/
    realpath.html>

    Suggests PATH_MAX *with* the zero byte, but the example uses an array
    of PATH_MAX + 1 bytes.

  2. Re: realpath

    vippstar@gmail.com writes:

    >hello comp.unix.programmer


    >Does realpath() write PATH_MAX bytes including or excluding the zero
    >byte?


    Yes.

    ><http://www.opengroup.org/onlinepubs/...399/functions/
    >realpath.html>


    >Suggests PATH_MAX *with* the zero byte, but the example uses an array
    >of PATH_MAX + 1 bytes.


    Wrong. Note that the example is NOT part of the "standard" (but it
    needs to be fixed)

    Casper
    --
    Expressed in this posting are my opinions. They are in no way related
    to opinions held by my employer, Sun Microsystems.
    Statements on Sun products included here are not gospel and may
    be fiction rather than truth.

  3. Re: realpath

    On Sep 16, 7:28 pm, Casper H.S. Dik wrote:
    > vipps...@gmail.com writes:
    > >hello comp.unix.programmer
    > >Does realpath() write PATH_MAX bytes including or excluding the zero
    > >byte?

    >
    > Yes.
    >
    > ><http://www.opengroup.org/onlinepubs/...399/functions/
    > >realpath.html>
    > >Suggests PATH_MAX *with* the zero byte, but the example uses an array
    > >of PATH_MAX + 1 bytes.

    >
    > Wrong. Note that the example is NOT part of the "standard" (but it
    > needs to be fixed)


    Thanks a lot.

  4. Re: realpath

    Casper H.S. Dik wrote:
    > vippstar@gmail.com writes:
    >
    >> hello comp.unix.programmer

    >
    >> Does realpath() write PATH_MAX bytes including or excluding the zero
    >> byte?

    >
    > Yes.


    So the "yes" presumably means "including". Is this the case across the
    board? There are a number of interfaces where I haven't been sure and
    have sometimes resorted to allocating PATH_MAX+1 bytes throughout a
    program. Is this an area where differing practice and backward
    compatibility make it impossible to issue a consistent rule, or can we
    safely assume[*] that PATH_MAX will always be the right number?
    [*] Where "assume" should not be read to mean that bounds checking isn't
    done.

    Arch Stanton

  5. Re: realpath

    Arch Stanton writes:

    >Casper H.S. Dik wrote:
    >> vippstar@gmail.com writes:
    >>
    >>> hello comp.unix.programmer

    >>
    >>> Does realpath() write PATH_MAX bytes including or excluding the zero
    >>> byte?

    >>
    >> Yes.


    >So the "yes" presumably means "including". Is this the case across the
    >board? There are a number of interfaces where I haven't been sure and
    >have sometimes resorted to allocating PATH_MAX+1 bytes throughout a
    >program. Is this an area where differing practice and backward
    >compatibility make it impossible to issue a consistent rule, or can we
    >safely assume[*] that PATH_MAX will always be the right number?


    PATH_MAX is the right number. Using something else is wrong but
    it is, unfortunately, common.

    Why would you create a #define and then require everyone to add one more?

    Casper
    --
    Expressed in this posting are my opinions. They are in no way related
    to opinions held by my employer, Sun Microsystems.
    Statements on Sun products included here are not gospel and may
    be fiction rather than truth.

  6. Re: realpath

    Casper H.S. Dik wrote:
    > PATH_MAX is the right number. Using something else is wrong but
    > it is, unfortunately, common.
    >
    > Why would you create a #define and then require everyone to add one more?


    I wouldn't, but that doesn't mean that, say, some grad student at UC
    Berkeley in the 1980s didn't misinterpret PATH_MAX. I'm happy to learn
    that that didn't happen.

    Arch Stanton

  7. Re: realpath

    Casper H.S. Dik wrote:

    > vippstar@gmail.com writes:
    >
    >><http://www.opengroup.org/onlinepubs/...399/functions/
    >>realpath.html>

    >
    >>Suggests PATH_MAX *with* the zero byte, but the example uses an array
    >>of PATH_MAX + 1 bytes.

    >
    > Note that the example is NOT part of the "standard" (but it
    > needs to be fixed)


    In the new revision the example is different anyway: it passes
    NULL as the second argument (to tell realpath() to allocate memory
    for the buffer).

    --
    Geoff Clare

  8. Re: realpath

    Arch Stanton wrote:

    > Casper H.S. Dik wrote:
    >> vippstar@gmail.com writes:
    >>
    >>> Does realpath() write PATH_MAX bytes including or excluding the zero
    >>> byte?

    >>
    >> Yes.

    >
    > So the "yes" presumably means "including". Is this the case across the
    > board? There are a number of interfaces where I haven't been sure and
    > have sometimes resorted to allocating PATH_MAX+1 bytes throughout a
    > program. Is this an area where differing practice and backward
    > compatibility make it impossible to issue a consistent rule, or can we
    > safely assume[*] that PATH_MAX will always be the right number?


    Since 2001 the POSIX standard has been clear that PATH_MAX always
    includes the terminating null, but earlier versions were ambiguous
    and some systems excluded the null.

    To complicate matters, in the new POSIX revision PATH_MAX is a
    "soft" limit. Implementations are allowed to accept pathnames
    longer than PATH_MAX in calls like open(), mkdir(), etc., and
    to return pathnames longer than PATH_MAX in getcwd() and in
    buffers allocated internally by realpath(). (If you pass your
    own buffer to realpath() it won't write more than PATH_MAX
    bytes, provided PATH_MAX is defined as a constant in .
    If PATH_MAX is not defined as a constant, the behaviour of
    realpath() with a non-null second argument is undefined.)

    --
    Geoff Clare

+ Reply to Thread