strcat+strcat+strcat == baaad

[Shachar Shemesh]

When I'm wrong, I'm wrong.

sun at sun:~/sources/wine/test$ gcc -O0 strcpy.c -o way1 -DWAY1
sun at sun:~/sources/wine/test$ gcc -O0 strcpy.c -o way2 -DWAY2
sun at sun:~/sources/wine/test$ gcc -O0 strcpy.c -o way3 -DWAY3
sun at sun:~/sources/wine/test$ ./way1
Operation took 0 seconds 450763 usec
sun at sun:~/sources/wine/test$ ./way2
Operation took 0 seconds 598408 usec
sun at sun:~/sources/wine/test$ ./way3
Operation took 0 seconds 427037 usec

With higher O values, the difference becomes bigger, but I'm not sure 
then that some of the operations are not optimized out of the process, 
which makes the entire benchmark useless.

So, what are our conclusions? Do we just implement strlcpy and strlcat 
so that everyone has a function that is both efficient AND secure?

Do we go for David's suggestion, that is more efficient, but is also 
more cubersome and requires two extra vars to implement right?

                Shachar

David Laight wrote:

>>I said that due to the wall to wall agreement over the superiority of 
>>sprintf/snprintf. If there is a consensus, we should stick to it.
>>    
>>
>
>But the performance of it will suck badly.....
>
>Something like:
>
>char *
>str_add(char *s, char *lim, const char *a)
>{
>	int c;
>
>	do {
>		if (s >= lim) {
>			s = lim - 1;
>			c = 0;
>		} else
>			c = *a++;
>		*s++ = c;
>	} while (c);
>
>	return s;
>}
>
>So you can do:
>	lim = buf + len;
>	buf = str_add(buf, lim, "abc");
>	buf = str_add(buf, lim, "123");
>	...
>might be safer.
>
>	David
>
>  
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: strcpy.c
Type: text/x-csrc
Size: 1780 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20021202/a12a10cd/strcpy.c