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

[Ledion B]

>n will _always_ be greater than strlen(src), at least
>99.99% of the cases. We are copying strings into 
>fixed-size buffers that always have enough room.

I was worrying about this being the case. So I did a
real quick scan through the *'s code and yes indeed
that is the case, that most of the time strncpy is
called with the size of the destination buffer. 

>There is no way to make sure that "n !> strlen(src)",
>that would require dynamically sized buffers, in
which >case there would be no need for strncpy at all.

Why dynamically sized buffers?? If you know (somehow
without calling strlen(src), the length of src) you
can predict whether padding will happen or not.

I think your implementation does make sense, in the
setting where strncpy is used to safeguard the
destination buffer. I've used strncpy to copy
substrings  most of the time, and almost never to
protect dst - dynamic alloc ;-/.

Here is some supporting data. At about 50% buffer
occupancy that's when strlen starts taking over. As
you can see knowing the length of src outperforms all
the rest -- if perfomance is the issue maybe we should
build functions that use structs and keep track of the
length of the string -- this will require MAJOR work
in part of replacing existing asterisk code.
ast_copy_string might be a good tradeoff.

length           -- the strlen(src)/src size 
ast_copy_string  -- time (ms) 10,000,000 calls
strncpy          -- time (ms) 10,000,000 calls, n =
100
strncpy(strlen)  -- time (ms) 10,000,000 calls,
n=strlen(n); (expression)

strncpy(len)     -- time (ms) 10,000,000 calls,
n=strlen(n) (value)


length   ast_copy_string         strncpy        
strncpy(strlen)         strncpy(len)
10/100  361     1336    574     320
12/100  426     1215    617     348
14/100  461     1313    700     395
16/100  527     1261    737     410
18/100  563     1340    820     473
20/100  628     1364    857     478
22/100  665     1395    1001    514
24/100  731     1350    1050    562
26/100  767     1381    1125    665
28/100  832     1400    1173    659
30/100  868     1393    1263    686
32/100  934     1390    1220    672
34/100  970     1423    1337    715
36/100  1035    1408    1370    781
38/100  1073    1442    1470    845
40/100  1137    1425    1520    869
42/100  1174    1473    1594    916
44/100  1239    1443    1653    934
46/100  1276    1476    1712    977
48/100  1342    1460    1773    1001
50/100  1383    1516    1840    1043
52/100  1442    1479    1892    1069
54/100  1479    1530    1972    1112
56/100  1544    1497    2012    1135
58/100  1581    1556    2080    1174
60/100  1646    1515    2138    1203
62/100  1682    1569    2228    1240
64/100  1748    1533    2251    1265
66/100  1784    1600    2316    1310
68/100  1850    1551    2371    1335
70/100  1886    1611    2432    1374
72/100  1952    1575    2492    1395
74/100  1988    1575    2554    1437
76/100  2054    1521    2610    1464
78/100  2089    1587    2673    1503
80/100  2155    1515    2730    1527
82/100  2140    1515    2790    1568
84/100  2140    1515    2850    1592
86/100  2140    1515    2910    1635
88/100  2141    1516    2969    1659
90/100  2141    1515    3030    1699
92/100  2140    1515    3090    1724
94/100  2140    1514    3150    1766
96/100  2140    1515    3209    1790
98/100  2141    1515    3269    1833
100/100 2140    1514    3330    1856


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com