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: PATCH: Return NULL on NULL bfd (Problem with linker with binutils-040414)


Hi Dave, Hi H.J.

 As to the pointfulness of doing so, ISTM unlikely that the knowledge (of
which function was calling b_a_f) on its own would ever be enough for
someone to fix a bug, so the usefulness of supplying that knowledge on its
own (by letting b_a_f return NULL) seems dubious to me.  I suppose that some
bugs might be so immediately obvious from the source code of the calling
function that just eyeballing it is enough to fix them, but I rather expect
that >95% of bugs will require someone to get out the debugger and have it
breakpoint at the failure, and at that point you get to see not just what
the calling function is but also all its internal variables, arguments it
was called with, etc etc.

 So it's supplying information that, while valid, is unlikely to ever be of
any actual help, at the cost of perhaps-sometimes-maybe invoking undefined
behaviour on some systems.

 Anyway, that's my take on it.  2c and all that.  But it's all rather
academic, and I don't think it matters a _great_ deal which solution is
applied in the end.  I'm happy with the abort, but basically the only *hard*
requirements I'd put on the solution myself are that it mustn't silently
generate invalid output files, and it should make it clear that the error is
an internal coding error requiring debugging, rather than one caused by (eg)
bad inputs.



OK - well at some point we need to reach a decision on which solution to choose, and since I am the maintainer I get to make the choice :-). So I say that we go with b_a_f() returning NULL. It may not please everyone but it is still what I believe to be the best compromise.

H.J. can of course always change this in his own binutils sources so there will be an alternative solution available for people who want that.

Cheers
 Nick


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