unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
* bug#69438: basename faulty with nul and suffix
@ 2024-02-27 20:14 Zefram via Bug reports for GUILE, GNU's Ubiquitous Extension Language
  2024-02-28  5:31 ` tomas
  0 siblings, 1 reply; 2+ messages in thread
From: Zefram via Bug reports for GUILE, GNU's Ubiquitous Extension Language @ 2024-02-27 20:14 UTC (permalink / raw)
  To: 69438

Trying out the basename function in Guile 3.0.9:

scheme@(guile-user)> (basename "foo/bar")
$1 = "bar"
scheme@(guile-user)> (basename "foo/bar" "r")
$2 = "ba"
scheme@(guile-user)> (basename "foo/bar" "x")
$3 = "bar"
scheme@(guile-user)> (basename "foo/bar\0baz/quux")
$4 = "bar"
scheme@(guile-user)> (basename "foo/bar\0baz/quux" "r")
$5 = "bar"
scheme@(guile-user)> (basename "foo/bar\0baz/quux" "x")
$6 = "ba"

The first three cases here show the function operating correctly on a
mundane pathname string.

The fourth case shows it operating in a debatable manner on a pathname
string that has an embedded nul.  This treatment of this case is based
on the idea that the string is acceptable as a pathname for file I/O
functions, and that the nul will serve to terminate the pathname (which
is what happens naturally in a naive treatment of passing the string to
a system call).  I note that the open-file function had that treatment
of embedded nuls in Guile 1.6, but that since Guile 1.8 it has instead
signalled an error on such a pathname string.  Are there any remaining
functions that accept embedded nuls in pathname strings?  If not, then the
basename and dirname functions probably ought to correspondingly signal
an error for an embedded nul.  (Incidentally, basename and dirname had
unambiguously incorrect treatment of embedded nuls prior to Guile 2.0,
so there's never yet been a version in which open-file and basename had
matching treatment of embedded nuls.)

But what I'm really interested in here is the fifth and sixth cases,
where there's an embedded nul in the pathname string and also a suffix
argument.  Accepting the interpretation of the embedded nul as correct,
the treatment here of the suffix is clearly faulty.  Whether the suffix
matches is being incorrectly checked against the original string, before
nul truncation, but the suffix removal is being applied to the correct
basename.  It's possible to give a suffix that matches the untruncated
string but is longer than the true basename, causing the suffix removal
to error due to indexing outside the string.  Whether the suffix matches
should instead be checked against the nul-truncated string.

-zefram





^ permalink raw reply	[flat|nested] 2+ messages in thread

* bug#69438: basename faulty with nul and suffix
  2024-02-27 20:14 bug#69438: basename faulty with nul and suffix Zefram via Bug reports for GUILE, GNU's Ubiquitous Extension Language
@ 2024-02-28  5:31 ` tomas
  0 siblings, 0 replies; 2+ messages in thread
From: tomas @ 2024-02-28  5:31 UTC (permalink / raw)
  To: 69438

[-- Attachment #1: Type: text/plain, Size: 1270 bytes --]

On Tue, Feb 27, 2024 at 08:14:58PM +0000, Zefram via Bug reports for GUILE, GNU's Ubiquitous Extension Language wrote:
> Trying out the basename function in Guile 3.0.9:
> 
> scheme@(guile-user)> (basename "foo/bar")
> $1 = "bar"
> scheme@(guile-user)> (basename "foo/bar" "r")
> $2 = "ba"
> scheme@(guile-user)> (basename "foo/bar" "x")
> $3 = "bar"
> scheme@(guile-user)> (basename "foo/bar\0baz/quux")
> $4 = "bar"
> scheme@(guile-user)> (basename "foo/bar\0baz/quux" "r")
> $5 = "bar"
> scheme@(guile-user)> (basename "foo/bar\0baz/quux" "x")
> $6 = "ba"
> 
> The first three cases here show the function operating correctly on a
> mundane pathname string.

Hm. The functions are clearly designated as POSIX. In POSIX, \0 is
explicitly excluded as a legal character in paths [1] [2]. I guess
the implementation is just passing the buck to the OS's basename(3).

Arguably, it'd be friendlier for the function to throw an error,
but then, it'd be inconsistent with the OS. You can't win :-)

Perhaps, a note in the docs wouldn't harm, though.

Cheers

[1] https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_266
[2] https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_169
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2024-02-28  5:31 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-02-27 20:14 bug#69438: basename faulty with nul and suffix Zefram via Bug reports for GUILE, GNU's Ubiquitous Extension Language
2024-02-28  5:31 ` tomas

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).