This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc 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: I: [PATCH] realloc-related memory leaks fixes


On Fri, 28 Dec 2001, Dmitry V. Levin wrote:

> Date: Fri, 28 Dec 2001 21:56:12 +0300
> From: Dmitry V. Levin <ldv@alt-linux.org>
> To: libc-alpha@sources.redhat.com
> Subject: [libc-alpha] Re: I: [PATCH] realloc-related memory leaks fixes
> 
> On Fri, Dec 28, 2001 at 10:05:42AM -0800, Ulrich Drepper wrote:
> > > > - __argz_add_sep() contains possible memory leak; its semantics differs
> > > >   from other argz functions (patch attached);
> > 
> > Something like this is completely unacceptable.  The self-acclaimed
> 
> Your reaction is easy to predict. :)

If you were able to predict that response, it means that you already
had a hunch that your proposed change wouldn't stand, but decided to
try it anyway. Next time, trust your hunch more.

In my experience, Ulrich Drepper rejects patches purely due to
engineering reasons.  It is only the one *proposed change* that is
``completely unacceptable'', not *you* or your participation in the
effort.  People who have proved to be sources of reliable patches
still have their work rejected from time to time.

If you feel personally slighted, even in the smallest degree, when a
patch is rejected, you must adjust your attitude. If that doesn't work,
write a patch that is acceptable and you will see.

It's far worse to be the skunk who broke the library for millions of
people, than to have a patch rejected, so be glad that there is
quality assurance to catch you.

The key to writing a successful patch is to identify something that
needs to be fixed, such that the fix has a high benefit and low risk.
A patch cannot be accepted if it introduces certain breakage, of it it
doesn't demonstrate any significant benefit; the correct thing is to
reject such a change, and that this will happen is quite predictable.


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