[asdf-devel] bug in new ASDF

[Robert Goldman]

Richard M Kreuter wrote:
> Gary King writes:
> 
>>> OK, I /have/ misdiagnosed this.  The logic seems actually busted in
>>> directory-pathname-p.  The problem is that, at least on allegro, you
>>> can get a valid directory pathname whose name component is neither
>>> NIL, nor :unspecific, but "" (the empty string).
>> Ugh,
>>
>>> (member (pathname-name pathname) (list nil "" :unspecific) :test  
>>> 'equal)
>>
>> A source of the problem are pathnames that arise from things like this:
>>
>>      > (make-pathname :name "" :directory '(:absolute "tmp"))
>>     #p"/tmp/"
>>      > (pathname-name *)
>>      ""
>>
>> Added a call to namestring seems to be another way to canonical things  
>> so I think this will also work and feels (to me) a bit more portable:
>>
>> (defun directory-pathname-p (pathname)
>>    (let ((pathname (namestring pathname)))
>>      (and (member (pathname-name pathname) (list nil :unspecific))
>> 	 (member (pathname-type pathname) (list nil :unspecific)))))
> 
> I see two problems:
> 
> (1) If the the host component of *DEFAULT-PATHNAME-DEFAULTS* is
>     different than the host component of PATHNAME, the parse might fail
>     or come out wrong.
> 
> (2) Pathnames with "" for the name component don't have namestrings
>     under SBCL.  (IIUC, the intent there is to try to have namestring
>     parsing and unparsing be non-lossy.)
> 
> I think it might do just as well to say that "" for the name counts the
> same as NIL or :UNSPECIFIC for DIRECTORY-PATHNAME-P, unless somebody
> knows of implementations that don't work that way.
> 

The problem with this is that it is open to the kind of attacks that
Andreas and Zach propose.  Note that those already break the existing
directory-pathname-p assumption that one can check the name and type
components separately....

[I am pleased to reveal that ACL, at least, throws away name fields of
"."...  Haven't checked SBCL, nor have I yet checked to see if these are
acceptable name components.]