This is the mail archive of the bfd@sourceware.cygnus.com mailing list for the bfd project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
In message <199812091735.MAA29788@subrogation.cygnus.com>you write: > > introduced with a change to the function a few months ago. The fix is > > to avoid introducing bugs; clearing memory is just treating the > > symptom. > > To me, clearing memory is the super set of setting one field to > zero. I am a better safe than sorry person. I have no time > to second guess if there is another field I should clear. > > I know you don't mean this, but to me ``I have no time to second > guess'' sounds like ``I have no time to figure out how the code works, > or what the right patch is.'' In a long running project like GNU, > anybody who wants to make changes has to take the time to understand > them. We're not quickly hacking stuff together for the big demo next > Wednesday; we're writing code that should, ideally, survive for twenty > years. > > I also agree with Roland's point. IMHO, clearing a block of memory to fix a problem without understanding precisely why clearing the block fixes the problem is just papering over a bug. Once one understands precisely why clearing one or more memory locations is fixing a bug, once can decide if clearing one or more fields or a whole structure/array is the best solution. I believe gdb operates under a similar guidelines. jeff