linux-kernel - Re: SLUB: Return ZERO_SIZE

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:	Fri, 1 Jun 2007 22:09:35 -0400 (EDT)
From:	"John Anthony Kazos Jr." <jakj@...-k-j.com>
To:	Christoph Lameter <clameter@....com>
cc:	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Jeremy Fitzhardinge <jeremy@...p.org>
Subject: Re: SLUB: Return ZERO_SIZE_PTR for kmalloc(0)

> +	 * The behavior for zero sized allocs changes. We no longer
> +	 * allocate memory but return ZERO_SIZE_PTR.
> +	 * WARN so that people can review and fix their code.

I don't see why people have so much opposition to zero-size memory 
allocations. There's all sorts of situations where you want a resizeable 
array that may have zero objects, especially in these days of 
hotpluggability.

Not only is it simpler (and therefore less likely to be buggy) to write 
code to simply resize to current number of objects, but not having to make 
additional code for checking the special case of count==0 leading to 
different function calls (instead of always reallocating, you might have 
to allocate instead, and instead of reallocating to zero you might have to 
free instead) will very slightly increase the object-text size.

The standard-C behavior of valid zero-size allocation has a very good 
reason.
-
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/