| |||||||||||||
|
| |||||||||||||
The thorny case of kmalloc(0)The thorny case of kmalloc(0)Posted Jun 7, 2007 11:17 UTC (Thu) by evgeny (guest, #774)In reply to: The thorny case of kmalloc(0) by dvrabel Parent article: The thorny case of kmalloc(0)
> 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.
(Log in to post comments)
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.
|
|
||||||||||||