[procps] Re: backporting
- From: Jim Warner <james.warner@xxxxxxxxxxx>
- To: procps@xxxxxxxxxxxxx
- Date: Wed, 7 Dec 2011 16:25:17 -0600
On Dec 7, 2011, at 3:52 PM, Sami Kerola wrote:
> Perhaps someone has a reason to relocate locales, and letting that to
> be possible does not seem to add complexity or other maintenance
> burden.
I was hoping you would agree as I'm still too new to autotools.
> I really think getting commands to up to date (no known bugs), and
> flushing everyone's change buffers to empty before touching the lib is
> a requirement. Otherwise we end up shooting moving targets which is
> bound to be difficult.
Agree and I've got a few more library changes pending.
> The real issue is that sometimes the library surprises, I'm sure you
> remember certain free() backfiring beyond anyone's expectation. That
> sort of dirtiness in library will drive it's users to crazy,
> especially when there is no documentation.
I don't remember this. I was out of the procps loop for about 7 years, until
top got so bad I couldn't take it anymore. Can you expand on that free()
business?
> Again question of portability expectations while some other headers
> make life easier. For example I really don't want to check malloc
> every single time separately. One extreme is not to use private
> libraries at all, and at other end of scale is gnulib. Somewhere in
> between sounds right to me.
The library already offered superior gcc attributes notation. And it had some
perfectly acceptable memory functions and will soon have one more (xstrdup).
Even top will be able to use those functions just as soon a Craig applies some
pending patches.
In summary, there was no need to reinvent those wheels when 80% of the need was
already met.
Regards,
Jim
Other related posts:
