["Eric Wedel" <ewedel@xxxxxxxxxxx>]

Bounds-checking to avoid buffer overflow might be a little
slower, but not as slow as dealing with an ethereal crash.
To say nothing of the security implications.

Are you suggesting strcpy() is not error-prone?

-----Original Message-----
From: ethereal-dev-bounces@xxxxxxxxxxxx
[mailto:ethereal-dev-bounces@xxxxxxxxxxxx]On Behalf Of Rich Coe
Sent: Friday, October 21, 2005 12:42 PM
To: Ethereal development
Subject: Re: [Ethereal-dev] strcpy harmful, what?


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

_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev

*********************************************************************************
This email and any attachment is confidential. It may only  be read, copied
 and used by the intended recipient(s). If you are not the intended recipient (s), you may not copy, use, distribute, forward, store or disclose this e-mail or any attachment. If you are not the intended recipient(s) or have otherwise received this e-mail in error, you should destroy it and any attachment and notify the sender by reply e-mail or send a message to: sysadmin@xxxxxxxxxxx.
*********************************************************************************