Re: CVS commit: src/lib/libc/stdlib

[Kamil Rytarowski <n54%gmx.com@localhost>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 09.08.2015 15:29, Joerg Sonnenberger wrote:
> On Tue, Jul 28, 2015 at 05:13:34PM +0000, Kamil Rytarowski wrote:
>> Module Name:	src Committed By:	kamil Date:		Tue Jul 28 17:13:34
>> UTC 2015
>> 
>> Modified Files: src/lib/libc/stdlib: reallocarr.3 reallocarr.c
>> 
>> Log Message: Compatibility fixes in reallocarr(3)
> 
> Except it is worse now. There is now an obscure assumption that 
> CHAR_BITS is 8, spelled via 2 == log_2 CHAR_BITS - 1.
> 


What do you think about the following patch:

Index: reallocarr.c
===================================================================
RCS file: /cvsroot/src/lib/libc/stdlib/reallocarr.c,v
retrieving revision 1.3
diff -u -r1.3 reallocarr.c
- --- reallocarr.c	28 Jul 2015 17:13:34 -0000	1.3
+++ reallocarr.c	16 Aug 2015 20:57:06 -0000
@@ -50,8 +50,6 @@
 #endif
 #endif

- -#define SQRT_SIZE_MAX (1UL << (sizeof(size_t) << 2))
- -
 #if !HAVE_REALLOCARR
 int
 reallocarr(void *ptr, size_t number, size_t size)
@@ -70,8 +68,7 @@
 		return 0;
 	}

- -	if ((number >= SQRT_SIZE_MAX || size >= SQRT_SIZE_MAX) &&
- -	    number > SIZE_MAX / size) {
+	if (number > SIZE_MAX / size) {
 		errno = saved_errno;
 		return EOVERFLOW;
 	}



I was benchmarking it on a modern amd64 processor and there is almost
no difference between (number >= SQRT_SIZE_MAX || size >=
SQRT_SIZE_MAX) vs (number > SIZE_MAX / size) for small 'number' and
small 'size'.

The reason to go for it is already prevented the 0 division with the
check in the free(3) case (number == 0 || size == 0).

In 90. division was an expensive operation, today not any more. I
would prefer to let it to be optimized by a compiler, not by a human
for a special or an old hardware with expensive arithmetic operations.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJV0PuKAAoJEEuzCOmwLnZsLmoP/3xbcc2XNXhyGmP/aZvZ9FTo
9ScYE50pV96J+UPmf5hM2kG7jUV7nIfPc3vSdP1UUi7Lg5B5gc6KKx9gCqPOn3PC
4HOcCLRRcO9R2VwNuTYSp5h1xRGgrKXt8fE5FEUA5WrMQ5+LgZ9nWQc1ZnLZFd38
Hir3o1AcjjLcLC2Xttq0CD9Uw7i1F5nUPMKfVgYo4CzYbLrTB+oXhymLOzqEcc2Q
N9aqUsFhCVphz24hH7KQX/sSbAykl6mBvv3JIGrurk6mby4UC2H26lEx+6LZw2eu
6TylkXrAmgC64Y5MhJkYnWDtKuwN09fr+zc0GsGpy4ZIEWD7rz1VCaovhLw2g7iV
u0ccHqe6ldLUzneqEKOIQJFTQU4ROM6KVhzCOrg4tTZw5MPd12ARYJz9hkdT9Nz1
clkH9+YMFZpRW9OnAze3U1APevmhP0qt7mpiWiMn8I49t+2fpMg5gt63dAyGLODw
tHK8IsCwuDp9TcvOI2iza+XhYpbBcjRoevTTciOa6xKougp62h+mCpIWrXGECKIz
Gomx3nzmIVAAVPIOoZAvwzD00n2vlVjjYEtw8fZ4q7QJueSYghhW/WSe4N6ZQDxD
OaTY0eeEOYHm9yGfy/L8sd5+jU7ehRbBHJ5MtAkFzO07HTeNmlMWtV1PV7VfAByB
e4MfvasHmIj5l7QQVyAo
=4eOR
-----END PGP SIGNATURE-----