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]
Message-ID: <alpine.DEB.0.99.0706012205080.1305@sigma.j-a-k-j.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ