file-namestring result shouldn't contain directory and device

[Anton Kovalenko]

Evaluate (file-namestring #P"/foo/bar/baz.txt").
Expected: "baz.txt"
Got: "/foo/bar/baz.txt"

Per CLHS entry on FILE-NAMESTRING, "file-namestring returns just the name, type, and version components of pathname.". SBCL is definitely non-conforming here.

[Anton Kovalenko (anton-sw4me)]

Sorry, that's invalid (my local windows-lfn-related change was the culprit)

[Anton Kovalenko (anton-sw4me)]

Sorry again, that's _not_ invalid, but it's really a bug in sb-simple-streams (file-namestring is redefined there).

[Anton Kovalenko (anton-sw4me)]

Patch for sb-simple-streams

[Orivej Desh (orivej)]

Analogous bug went into 1.1.4, but it no longer appears in master.

[Orivej Desh (orivej)]

Sorry, looked insufficiently well. The erroneous behaviour is introduced by loading sb-simple-streams.

[Christophe Rhodes (csr21-cantab)]

 status fixcommitted
 tag -review
 done

Anton Kovalenko <email address hidden> writes:

> Public bug reported:
>
> Evaluate (file-namestring #P"/foo/bar/baz.txt").
> Expected: "baz.txt"
> Got: "/foo/bar/baz.txt"
>
> Per CLHS entry on FILE-NAMESTRING, "file-namestring returns just the
> name, type, and version components of pathname.". SBCL is definitely
> non-conforming here.

I've fixed this in a different way; I think FILE-NAMESTRING in
SB-SIMPLE-STREAMS was intended to be a utility function, not a
reimplementation of the CL function, and because of the :IMPLEMENTS
clause in the package this didn't trigger any warnings. Thanks for the
report.

Christophe

commit 2fb9cd4a2286b82e065d6c673d91e46bd7f2194d
Author: Christophe Rhodes <email address hidden>
Date: Mon Sep 9 15:09:42 2013 +0100

    rename SB-SIMPLE-STREAMS utility function

    At least, I think it was simply intended to be a utility function,
    but the FILE-NAMESTRING name is unfortunate, as that's a CL
    function, and (for other reasons) SB-SIMPLE-STREAMS claims to
    implement CL in the package lock sense, so this was not noticed at
    the time.

    This fixes lp#884603; I am unconvinced that the namestring logic is
    actually correct (keeping the distinction between NAMESTRING and
    NATIVE-NAMESTRING clear) but I'll wait for an actual user to
    complain about that before thinking too hard.