Re: Problem with linker with binutils-040414

["H. J. Lu" <hjl at lucon dot org>]

On Mon, Apr 19, 2004 at 11:43:31AM -0400, Ian Lance Taylor wrote:
> "H. J. Lu" <hjl@lucon.org> writes:
> 
> > On Mon, Apr 19, 2004 at 10:35:34AM -0400, Ian Lance Taylor wrote:
> > > "H. J. Lu" <hjl@lucon.org> writes:
> > > 
> > > > I disagree. Did you mean "memset (0, 0, 1)" shouldn't segfault since
> > > > it was a library function? A NULL bfd won't give any meaningful
> > > > information in this case since the caller wants to get the filename.
> > > > The caller misuses the function and it deserves whatever it gets. I
> > > > don't believe it is wrong for a library not to support it misuse which
> > > > will only hide the caller's mistake and hurt the caller in the long
> > > > run.
> > > 
> > > memset has no defined way to report errors.  This is because it is
> > > coded for efficiency.  The argument does not apply to the BFD
> > > functions, nor to all libc routines.  If you call open(NULL, 0), you
> > > will get an error return with errno set to EFAULT.  You will not get a
> > > core dump.  The BFD functions should operate in the same way, within
> > > reason.  It's OK for bfd_get_32 to core dump, because it is an
> > > efficiency routine.  It's not OK for bfd_openr to core dump.
> > 
> > What is the defined way for bfd_archive_filename to report an error?
> > How should it be used? I don't believe bfd_archive_filename should
> > return a bogus filename on a bogus input to hide the caller's mistake.
> > It does no one good.
> 
> Well, that I agree with.  A bogus filename doesn't make sense.  It
> should presumably return NULL.
> 

Return NULL, abort or segfault are OK with me in this case.


H.J.