Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Ethereal-dev: Re: [Ethereal-dev] strcpy harmful, what?

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Rich Coe <Richard.Coe@xxxxxxxxxx>
Date: Fri, 21 Oct 2005 14:42:18 -0500
I think that replacing strcpy with a library function that (eventually)
calls strcpy (strncpy) a pointless, stupid exercise.

It's slower and error prone.

On Fri, 21 Oct 2005 10:44:48 +1000
ronnie sahlberg <ronniesahlberg@xxxxxxxxx> wrote:
> there was discussion and the developers consensus was that they should all
> be gone.
> 
> i have soon removed all the strcpy and will proceed to remove all strcat as
> well.
> 
> the goal is to make ethereal more stable and also remove a lot of the memory
> leakage.
> i think it is semisuccessful since so far this work has shown up a
> significant number of array out of bounds and memory leakage.
> this makes ethereal more stable.
> 
> 
> after all of them are gone i will ask gerald to add a grep -r to the
> buildbot to have it fail a build if it detects any strcpy/strcat calls in
> the code, if new ones manage to sneak in.
> 
> 
> g_snprintf() is slightly more computational expensive than strcpy but it is
> safer.
> 
> the performance bottlernecks lies elsewhere, not with g_snprintf.
> for ethereal: using strcpy as a speed optimization is at best a pointless
> microoptimization
> of code paths that were never taking up any noticeable time anyway.
> perfromance regression at all by these changes.
> In fact it might even become faster in some cases since many of those
> strcpy() could when combined with the emem allocator be completely replaced
> by just a simple pointer assignment.
> i.e. i dont think it will really be noticeable.
> 
> 
> another thing that needs to be done and will be completed eventually is to
> remove every single static or automatic array and replace with emem
> allocated memory.
> in particular all automatic arrays should go as priority one, later also the
> global ones.
> 
> all help and patches to speed this up is more than welcome.
> 
> 
> On 10/21/05, Rich Coe <Richard.Coe@xxxxxxxxxx> wrote:
> >
> > /* RANT on */
> > I think I missed the discussion where replacing strcpy with g_sprintf
> > was considered a good idea.
> > /* RANT off */
> >
> > Can someone explain why it's better to call a function which does
> > - varargs
> > - parses a string for formatting chars
> > - calls strncpy!
> > - calls strlen!
> > is much better than a simple copy.
> >
> > Thanks.
> > --
> > Rich Coe richard.coe@xxxxxxxxxx
> > General Electric Healthcare Technologies
> > Global Software Platforms, Computer Technology Team
> >
> > _______________________________________________
> > Ethereal-dev mailing list
> > Ethereal-dev@xxxxxxxxxxxx
> > http://www.ethereal.com/mailman/listinfo/ethereal-dev
> >
> 


-- 
Rich Coe		richard.coe@xxxxxxxxxx
General Electric Healthcare Technologies
Global Software Platforms, Computer Technology Team