Re: realpath(3)

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Thu, 25 May 2023 09:48:13 +0200
    From:        tlaronde%polynum.com@localhost
    Message-ID:  <ZG8SvdJN1JLi4k1S%polynum.com@localhost>

  | This does mean that calling realpath(3) with an input on which
  | realpath(3) will choke leads to precisely call mount() with the
  | offending part.

I agree that what is happening in mount there looks to be wrong
(not that realpath often fails).

  | IMO, this extension to realpath(3) behavior should be suppressed,

No, it can be useful.   In the POSIX spec what is left in the buffer
passed in (when not NULL) when realpath fails is undefined - that's
because different implementations do different things, and use, or
don't, the supplied buffer in different ways while executing the function.
When an error occurs, it just gets left in whatever state it was in at
that point.

NetBSD has chosen to define what that will be, as (because of what happens
to be left there) it can be useful for applications that want to attempt
to diagnose the problem better.   Truly portable applications (which mount
will never be - there's no mount command in POSIX) should not use the
contents of the buffer for anything, when realpath returns NULL.

  | and pathadj() should be fixed.

Yes, that looks likely.

kre