Juan Jose Garcia-Ripoll <juanjose.garciarip...@googlemail.com> writes:
> On Thu, Jan 13, 2011 at 5:09 PM, Pascal J. Bourguignon > <p...@informatimago.com> wrote: > > 19.2.2.2.3.1 is even more specific, specifying that both :unspecific and > nil should be converted to namestrings without the component. > >From this, I would expect an implementation on unix to accept > :unspecific and cause no problem with unix pathnames. > > I believe the clarifying point is here in CLtL > > http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node204.html#SECTION002711000000000000000 > Programming hint: portable programs should be prepared to handle the > value :unspecific in the device, directory, type, or version field in > some implementations. Portable programs should not explicitly place > :unspecific in any field because it might not be permitted in some > situations, but portable programs may sometimes do so implicitly (by > copying such a value from another pathname, for example). > > Regarding Section 19.2.2.2.3.1 and file operations, ECL so far has > adopted the convention that only pathnames which can be printed > readably can be "opened". In other words, each file has associated a > unique absolute physical pathname (not namestring) > > Precisely because of what you mention (19.2.2.2.3.1), pathnames with > :unspecific can not be printed readably. If one decides that #p"foo" > represents a file with :TYPE NIL, then it can not represent a file > with :TYPE :UNSPECIFIC > > That is unrelated to namestrings, though the ECL routine > ecl_namestring() has an option to stop translating a pathname when it > finds that it can not be printed readably. > > Maybe this is not a wise choice but it is consistent. I am open to > other possibilities and not too incompatible changes. 19.2.2.2.3 :UNSPECIFIC as a Component Value When writing[1] the value of any pathname component, the consequences are undefined if :unspecific is given for a pathname in a file system for which it does not make sense. ECL could define that :unspecific doesn't make sense for types, and could define that it is mapped to NIL. ie. pathname-type could never return :unspecific (and similarly for other components). -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}. ------------------------------------------------------------------------------ Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
