file-error and reference condition for (namestring (make-pathname :type "ext"))

[mon_key]

Please provide some documentation of pathname objects "(with no namestring)"
the behaviour is sometimes less than obvious.

*(make-pathname :type "bmp")
; => #<PATHNAME (with no namestring)
; :HOST #<SB-IMPL::UNIX-HOST {91684C1}>
; :DEVICE NIL
; :DIRECTORY NIL
; :NAME NIL
; :TYPE "bmp"
; :VERSION NIL>

The spec says the above is kosher.

,---- 19.1.2 Pathnames as Filenames
|
| The mapping of the pathname components into the concepts peculiar to
| each file system is implementation-defined. There exist conceivable
| pathnames for which there is no mapping to a syntactically valid
| filename in a particular implementation. An implementation may use
| various strategies in an attempt to find a mapping; for example, an
| implementation may quietly truncate filenames that exceed length
| limitations imposed by the underlying file system, or ignore certain
| pathname components for which the file system provides no support. If
| such a mapping cannot be found, an error of type ‘file-error’ is
| signaled.
|
`----

But, in so much as its implementation-defined it would be nice to know
how/when/why.

(namestring (make-pathname :type "bmp"))

Really, why signal a SIMPLE-ERROR around the NAMESTRING callpoint instead of
signaling a FILE-ERROR when MAKE-PATHNAME recieved a :type specifier a its sole
argument?

(namestring (make-pathname :name nil :type nil :version nil))

(namestring (merge-pathnames (make-pathname :type "bmp") (pathname "")))

(merge-pathnames (pathname "") (make-pathname :type "bmp"))

(merge-pathnames (make-pathname :type "bmp") (pathname ""))

(sb-ext:native-namestring (merge-pathnames (make-pathname :type "bmp") (pathname "")))

(sb-ext:native-pathname (make-pathname :directory "" :type "bmp"))

(sb-ext:native-pathname (make-pathname :directory ""))

(pathname-type (make-pathname :type "bmp"))

--
/s_P\

[Christophe Rhodes (csr21-cantab)]

 status wishlist
 done

mon_key <email address hidden> writes:

> Please provide some documentation of pathname objects "(with no namestring)"
> the behaviour is sometimes less than obvious.

Possibly, though the existence of pathnames with no namestrings is a
direct conclusion from the specification, so it's not clear what extra
information can be provided by documenting them. (In general, I don't
think the sbcl manual is the place for resolving every simple confusion
any user has ever had: there are perfectly good introductory CL texts,
some of which even discuss pathnames in some detail).

> Really, why signal a SIMPLE-ERROR around the NAMESTRING callpoint
> instead of signaling a FILE-ERROR when MAKE-PATHNAME recieved a :type
> specifier a its sole argument?

This is easy to answer: because the pathnames that have no namestrings
can be merged with other pathnames.

Christophe

[Nikodemus Siivola (nikodemus)]

There are two things in this area that /should/ be fixed, though.

1. We currently signal a SIMPLE-ERROR, not a FILE-ERROR -- which would give convenient access to the offending pathname, and is required by the spec.

2. We should make it a reference condition, pointing 19.1.2.