This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Gas vs irregular files


Hi Nick,

> >  This patch:
> >
> > http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gas/input-file.c.diff?r1=1.11&r2=1.12&cvsroot=src
> >
> > breaks setups that invoke gas on non-regular files, e.g. like:
> >
> > $ as -o /dev/null /dev/null
> >
> > which may be used to check for supported command line options.
> 
> Urk - is this really done ?

 Hmm, any proposal on how to do that another way?  BTW, this is being done 
for gcc as well.

> One workaround would be to use an empty file:
> 
>     % rm -f empty.s
>     % touch empty.s
>     % as -o /dev/null empty.s
>     % rm empty.s
> 
> Although I suspect that this would not be popular.

 Well, my current approach is to use:

$ as -o /dev/null - </dev/null

instead, but I'm not that happy about having to change it at all.

> > And I find the new setup breaking the *nix tradition of treating all
> > files the same as far as possible.
> 
> How so ?

 About every program I know that operates on files doesn't do any checks,
relying on the operating system to return errors for unsupported
operations.  This approach often lets these programs to be used in unusual
ways for purposes their authors haven't anticipated.  As you may know
"/dev/null" was specifically invented to avoid the need of empty files in
some contexts and now you invalidate this feature.

> > The ChangeLog entry states it's for detecting directories -- if so,
> > it should do that explicitly with S_ISDIR().
> 
> Well yes and no.  The point is that it is not sensible to attempt to
> assemble anything other than a regular text file.  Hence the code uses
> S_ISREG() to check for files for which there is no point in even
> attempting to call open() or read().

 How do you know in advance?

> > And why has it be done at all?  If a system doesn't support reading 
> > directories, it'll refuse to do so.
> 
> And if it does support them ?  What is the assembler supposed to do
> with them ? Assemble every source file it finds in the directory ?

 Yup, if ordered to do so.  The user knows better what he wants to do.

> I am not against altering this patch if necessary, but I would like to
> know why the current behaviour is wrong.

 The user shouldn't be forced to circumvent unnecessary safety checks.

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]