[Bug-openmcl] pathnames

[Gary Byers]

On Wed, 21 Jan 2004, bryan o'connor wrote:

> [an implied "as i understand it" for all of this below]
>
> the issue with (make-pathname) setting :UNSPECIFIC for host
> and version arises when using merge-pathnames.
>
> (pathname-version (merge-pathnames (make-pathname) #p"foo" :NEWEST))
> returns :UNSPECIFIC with openmcl and :NEWEST on sbcl.
>
> the standard says that make-pathname will fill in any non-
> specified fields with values from *default-pathname-defaults*
> and NIL otherwise.
>
> *default-pathname-defaults* doesn't specify anything for
> host and version.. while not technically wrong, i think it's
> problematic in that it doesn't do what the user would expect.
>
> two solutions are adding :UNSPECIFIC to *default-pathname-defaults*
> (which means adding slots to %pathname or changing it to type
> %logical-pathname) or changing (make-pathname) to set NIL slots
> instead.
>

The third approach is "throw out the pathname code and start over".
Not as easy as it sounds (or necessarily a good idea), but it often
seems attractive.

> adding the slots to to %pathname could help with the :WILD
> failures with pathname-host and pathname-version.

It probably would be right to do this on general principles; I'm
sure that someone once thought that leaving the fields out would
be a Big Space Saving Win.  Uh, no ...

>
> like most of the other remaining failures, there don't really
> seem to be bugs -- more like "nitpicks".  i think we've
> cleaned up most of the major bugs.

I don't know if you caught this, but (prior to sometime last night):

(defun foo (x)
  (ash x 27))

would complain that (SIGNED-BYTE 1) isn't a valid type specifier.
It is, but the compiler's notion of how wide something has to be
so that the result of shifting it left N bits will fit in a fixnum
was based on how big fixnums were in 68K MCL as of about 1988.
Apparently, noone's shifted anything by exactly 27 bit in the last
15 years.

>
> 				...bryan
>
> _______________________________________________
> Bug-openmcl mailing list
> Bug-openmcl at clozure.com
> http://clozure.com/mailman/listinfo/bug-openmcl
>
>