Re: [Nasm-devel] 2.00rc2 Feedback

[Keith K. <ke...@ka...>]

H. Peter Anvin wrote:
> anonymous coward wrote:
>   
>>> One thing you might want to add: if anyone is willing to write a
>>> pathname manipulation library in portable C that handles all common
>>> platforms, we might consider using it for a future version.  Again,
>>> Perl's File::Spec has some good API ideas.
>>>       
>> Btw, I think you would also need an option for
>> controlling whether include files are looked up
>> in the main file's directory and/or in the CWD,
>> and you would need to think about backwards
>> compatibility, i.e. the default state of the option.
>>
>> As handy as the extra lookup capability might
>> seem to users who are too lazy to provide the
>> proper -I option(s)... it would be dangerous for
>> those who don't want such files to be located.
>>
>> Last but not least, if you are using GNU make,
>> then you may want to check out the -C option.
>> Although... if you were too lazy to provide -I to
>> NASM, then you're probably too lazy for -C.  :)
>>
>>     
>
> Well, gcc having a different default behaviour makes me somewhat 
> concerned about it.
>
> I realized driving home today that the problem isn't as painful as first 
> throught; we subset of pathname functionality we need isn't as tricky as 
> the whole problem.
>
> In particular, all known pathname syntaxes, even VMS, lets one splice 
> the string into a directory part and a filename part by scanning 
> backwards for one or more stop characters.
>
> In particular:
>
> Unix:		'/'
> WinDOS:		'/', '\' or ':'
> VMS:		']' or ':'
> MacOS Classic:	':'
> Multics [!]:	'>'
>
> This arranges for separation of a pathname.
>
> Joining a pathname usually involves a rule for when to insert a 
> separator character and when not to:
>
> Unix:		add '/' unless dir is empty or ends in '/'
> WinDOS:		add '\' unless dir is empty or ends in '/', '\' or ':'
> VMS:		never add anything
> MacOS Classic:	add ':' unless dir is empty or ends in ':'
> Multics:	add '>' unless dir is empty or ends in '>'
>
> I don't know how to deal with pathnames on IBM mainframe operating 
> systems, but I don't care: NASM already assumes that host system is 
> ASCII-based.
>
> Still, this is distinctly not a stop-ship for 2.00.
>   


The basic fact that this DEV group has incurred a lengthy conversation, 
mostly trying to identify exceptions and how to handle them, should be a 
big wake-up call as to the fact that maybe this kind of "support" is not 
worth the trouble. There should never be more exceptions than rules, 
unless that is apart of the core design.

Let's try not to be like everyone else, and let's do things for the 
right reasons... not for the popular or "lazy" ones.