On Tue, 16 Jan 2001, Guy Harris wrote:
> On Tue, Jan 16, 2001 at 09:19:23PM +0200, Pekka Savola wrote:
> > E.g. my savestr -> strdup patch apparently got rejected (I've sent out
> > workarounds though) because of a fear some ancient system might not have
> > strdup(3),
>
> Well, there's another reason not to automatically pick it up - the
> comment at the front of "savestr()" says
>
> /* A replacement for strdup() that cuts down on malloc() overhead */
>
> so the LBL folk were aware of "strdup()", but thought their version was
> better in some fashion.
>
> Their version, instead of allocating a new buffer for every string,
> allocates buffers that are a minimum of 1024 bytes long, and, if the
> string is shorter than 1K bytes, leaves the rest of the buffer available
> for the next string, so that fewer "malloc()" calls are made - they're
> trading space for time.
>
---
> Perhaps they were mistaken in their belief that this was a Good Idea,
> but it still might be worth testing the performance effects of using
> "strdup()" instead of "savestr()".
Very much so.
Not to mention the fact that the implementation was broken in the first
place. This caused traceroute-1.4a5 local root hole this summer. See:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=13466
savestr isn't used anywhere that'd be too time-critical AFAIR. I wager
there are a lot more optimizable things out there. Chris Evans put it:
---
Worse, the concept of savestr() looks broken. The code comment says it is
there to "reduce malloc() overhead incurred by strdup()". That's a
horrendous case of a programmer inventing a problem. savestr() is only
used a few times.
As if a few malloc() calls make a discernible difference in a program like
traceroute!! If only programmers would base their code on real-world measurements
rather than guessing.... :-)
---
Granted, it's used in addrtoname that is used now and then. But I'm sure
by the same analogue there are a lot of other calls in there that could be
"optimized".
> > Personally, I see no reason for supporting libc5 or the like anymore.
>
> Did Slackware go to glibc2 only relatively recently? If so, then if it's
> not too much effort to make it work - for example, if it just means not
> including <netinet/if_ether.h> if the system doesn't have such a header
> file - it might be worth doing that.
Easy fixes are always of course a good thing. Sometimes you just have to
let go though.
--
Pekka Savola "Tell me of difficulties surmounted,
Netcore Oy not those you stumble over and fall"
Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
