| |||||||||||||
|
| |||||||||||||
The thorny case of kmalloc(0)The thorny case of kmalloc(0)Posted Jun 7, 2007 10:02 UTC (Thu) by evgeny (guest, #774)Parent article: The thorny case of kmalloc(0)
> The problem here is that a NULL pointer is already loaded with meaning. It says that the allocation has failed
Right, but inventing ZERO_SIZE_PTR doesn't solve this problem; instead it delegates the punishment of the extra check to all possible users of the object, i.e. instead of
if (!a) {
one has to use
if (!a || a == ZERO_SIZE_PTR) everywhere. Not?
PS. Why in the "Plain text" format the indentation is not preserved?
(Log in to post comments)
The thorny case of kmalloc(0) Posted Jun 7, 2007 10:58 UTC (Thu) by dvrabel (subscriber, #9500) [Link] No. Either: a) you wanted a zero-size allocation know not to use the pointer; or b) the zero size allocation was a bug and should be detected as a error that's distinct from a out of memory error (i.e., any attempted use should fault). If you wish to defensively program a function against a caller requesting zero-sized allocations it would be better to test before attempting the allocation.
The thorny case of kmalloc(0) Posted Jun 7, 2007 11:17 UTC (Thu) by evgeny (guest, #774) [Link] > If you wish to defensively program a function against a caller requesting zero-sized allocations it would be better to test before attempting the allocation.
Well, that's the right way in my opinion. It needs only one check per kmalloc() call, while using two flavors of NULL forces to implement this check for each (out of, in general, >= 1 cases) access to pointer.
The thorny case of kmalloc(0) Posted Jun 7, 2007 11:59 UTC (Thu) by HenrikH (guest, #31152) [Link] And you are correct, but since there is people who apparantly uses kmalloc (0) I can se no other way to solve this problem. Either we let kmalloc return NULL only on error and not let size=0 be an error or we have to convert all these kmalloc(0) cases which turnoed out be quite a job.
The thorny case of kmalloc(0) Posted Jun 8, 2007 0:41 UTC (Fri) by bronson (subscriber, #4806) [Link] The article gives a perfectly good reason why kmalloc(0) is a decent thing to do: when the config has resulted in a struct with 0 members. Much easier just to kmalloc(0) and continue as normal rather than scattering more #ifdefs or macros everywhere.
(there's no need to test for ZERO_SIZE_PTR in this case because the struct has no members so the pointer can not be dereferenced anyway; you'll get a compile-time error instead of an oops)
The thorny case of kmalloc(0) Posted Jun 7, 2007 13:49 UTC (Thu) by dvrabel (subscriber, #9500) [Link] You're not supposed to test for ZERO_SIZE_PTR, but let the system oops if it's dereferenced.
The thorny case of kmalloc(0) Posted Jun 7, 2007 18:27 UTC (Thu) by pj (subscriber, #4506) [Link] Exactly... it should be valid to allocate 0 bytes of memory as long as you don't try and dereference the pointer and use it for anything. Consider code like:
items[] itemblock = kmalloc( itemcount * sizeof(items) );
ASSERT(itemblock != NULL);
for(int i = 0; i++ ; i < itemcount) {
...do something with itemblock[i]...
}
itemcount is allowed to be 0 in the above code, with no problems. a kmalloc(0) occurs, but the for loop never gets its body run, so itemblock is never dereferenced. At the same time, the ASSERT only happens when there's a problem allocating memory.
It's a good solution. And I like Linus' comment :)
The thorny case of kmalloc(0) Posted Jun 8, 2007 16:05 UTC (Fri) by giraffedata (subscriber, #1954) [Link] the ASSERT only happens when ...Grrr. The ASSERT always "happens" -- it's right there in unconditional code. The assertion fails only when ... And really, it shouldn't even be discussed. If you're asserting that the pointer is not null, that means you're assuming for simplicity that the the allocation didn't fail and if you discuss the possibility that it did fail, you've defeated the purpose of the assertion. This code should probaby be instead an explicit test of the pointer for NULL.
|
|
||||||||||||