This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Problem with linker with binutils-040414
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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.
And I would like open(NULL, 0) to segfault. I want my program to tell
me I have a *bug*, not a wrong filename. There's a world of difference
between the helpfulness (to a coreutils developer, anyway!) between
$ cat
Segmentation fault (core dumped)
$
and
$ cat
cat: (nil): Bad address
$
(Well, maybe a _small_ world of difference, like Quaoar.)
The first leaves a core dump, telling one exactly where the problem
first occurred, whereas the second needs wading through layer upon layer
of error-handling code.
Invalid input, however, should never cause segfaults. If it can cause
segfaults, it can probably cause arbitrary code execution.
- --
http://voyager.abite.co.za/~berndj/ (up again for now - yay!)
bernd's stupid blog: http://voyager.abite.co.za/~berndj/blog.php
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQFAg+37/FmLrNfLpjMRAq1IAKCLxeZazv//XsaS38StjzYKtI7OfQCbBfPt
AZ8P6jKu6bNXQKxB4m3uP1k=
=WkVY
-----END PGP SIGNATURE-----