linux-kernel - Re: strncpy optimalisation? (lib/string.c)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 10 Dec 2006 22:06:14 +0100
From:	Willy Tarreau <w@....eu>
To:	Folkert van Heusden <folkert@...heusden.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: strncpy optimalisation? (lib/string.c)

On Sun, Dec 10, 2006 at 09:52:30PM +0100, Folkert van Heusden wrote:
> Hi,
> 
> In lib/string.c we have:
> 
> char *strncpy(char *dest, const char *src, size_t count)
> {
>         char *tmp = dest;
> 
>         while (count) {
>                 if ((*tmp = *src) != 0)
>                         src++;
>                 tmp++;
>                 count--;
>         }
>         return dest;
> }
> 
> now I wonder isn't this ineffecient when strlen(src) < count? It would
> then, if I'm correct, iterate count-strlen(src) times doing useless
> increment/decrement. And since there are aprox. 580 instances in the
> 2.6.18.2 source, maybe some efficency can be won here.
> Wouldn't it be better to do:
>                 if ((*tmp = *src) == 0x00)
>                         break;
> 
> So that would be:
> --- lib/string.c	2006-11-04 02:33:58.000000000 +0100
> +++ string-new.c	2006-12-10 21:50:05.000000000 +0100
> @@ -97,8 +97,8 @@
>  	char *tmp = dest;
>  
>  	while (count) {
> -		if ((*tmp = *src) != 0)
> -			src++;
> +		if ((*tmp = *src) == 0x00)
> +			break;
>  		tmp++;
>  		count--;
>  	}

While your code is faster, it does not do exactly the same.
Original code completely pads the destination with zeroes,
while yours only adds the last zero. Your code does what
strncpy() is said to do, but maybe there's a particular
reason for it to behave differently in the kernel (helping
during debugging, or filling specific structs).

Just out of curiosity, have you tried to do a general
benchmark to check if original code eats much CPU ?

Regards,
Willy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/