[Asterisk-Dev] [RFC] strncpy -> ast_copy_string

Kevin P. Fleming kpfleming at digium.com
Sun May 1 23:05:22 MST 2005


Tilghman Lesher wrote:

> Okay, let me get this straight.  You want us to use a function that
> performs slightly slower than the library implementation and offers no
> real advantage (other than some belief that it's "more right").  I'm
> scratching my head.  Why are we doing this?

Uhh... why are putting words into my mouth here? I guess I wasn't 
explicit enough...

> It might be different if it was actually faster, but you've already
> tested that and found it not to be the case.  Let me remind you that
> Asterisk's primary purpose to process calls.  Anything that slows
> down that processing and decreases the number of calls we're able
> to process needs a real good reason.  Less work is _only_ a valid
> reason if CPU time is decreased.  More work or no, the library
> implementation is faster, so that's what we need to keep.

No, I did not "find it to not be the case". I know that the raw "byte 
copying" loop in ast_copy_string is slightly slower than strncpy's 
byte-copying loop, but the overall performance is a significant 
improvement, since strncpy always writes into every byte of the 
destination buffer. In fact, just simple logic would dictate that it 
would _have_ to be faster, unless the byte copying loop was poorly coded 
(which it is not).

In the vast majority of cases in my test Asterisk system, the strncpy 
calls are copying strings that consume 25% or less of the target buffer, 
and in a great deal of cases (the dialplan specifically) they are 
consuming less than 10% of the target buffer. strncpy is writing zeroes 
into 75%/90% of the buffer when it's totally unnecessary.

Is that explicit enough?



More information about the asterisk-dev mailing list