file-error and reference condition for (namestring (make-pathname :type "ext"))
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
SBCL |
Fix Released
|
Wishlist
|
Unassigned |
Bug Description
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:
; :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-
| 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-
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:
(sb-ext:
(sb-ext:
(pathname-type (make-pathname :type "bmp"))
--
/s_P\
Changed in sbcl: | |
status: | Triaged → Fix Committed |
Changed in sbcl: | |
status: | Fix Committed → Fix Released |
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