Re: realpath(3)

[tlaronde%polynum.com@localhost]

Hello Robert,

Le Thu, May 25, 2023 at 07:26:02PM +0700, Robert Elz a écrit :
>     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.

I will beg to differ.

This example, IMO, shows that using the same variable to hold
whether the canonical result to be used, or an error, that shall
NOT be used, relying on programmers to test correctly the return
status of a routine, is dangerous.

IMHO, realpath(3) should be a wrapper around a xplpath(3) ("explicate
path", or whatever name seems fitting for an english native
speaker---which I'm obviously not) that would take a char ** as
third argument whose value, if not NULL, will be defined so to
point after the part successfully processed (hence, in case of
failure, one can know where the routine choked).

And would it be good then to define, in case of error, resolvedname
with a name (is the empty string safe?) that for sure will make
any operation on this path fail?
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C