On Mon, 4 Jun 2007, Alan Cox wrote:
> > The thing is, why *should* we care about comparing addresses? We'll give > > Because people use it to tell objects apart. All over the kernel we do > things like > > if (inode1 == inode2) But that only makes sense if your objects have meaning, which is not possible with a zero-sized object. Let's take an example: one of the few reasons to check for equality (or inequality) is for locking order. So on UP, the lock goes away, and let's say that you (insanely) only have a spinlock in the structure in question, so you have a zero-sized structure that you want to test ordering on because you want to avoid ABBA deadlocks. So you write your code as double_lock() { if (ptr1 == ptr2) { lock(ptr1->lock); return; } if (ptr1 < ptr2) { lock(ptr1->lock); lock(ptr2->lock); return; } lock(ptr2->lock); lock(ptr1->lock); } and the interesting thing is that this actually *works* even for the case where the lock has gone away: even though ptr1/ptr2 are always equal. In other words, the only _valid_ reasons to compare pointers like this end up degenerating into working cases even for a zero-sized pointer. The exception is if you use the memory allocator as a "ID allocator", but quite frankly, if you use a size of zero, it's your own damn problem. Insane code is not an argument for insane behaviour. If people can't be bothered to create a "random ID generator" themselves, they had damn well better use "kmalloc(1)" rather than "kmalloc(0)" to get a unique cookie. Asking the allocator to do something idiotic because some idiot thinks a memory allocator is a cookie allocator is just crazy. I can understand that things like user-level libraries have to take crazy people into account, but the kernel internal libraries definitely do not. (Right now we warn once for zero-sized allocations anyway, and all the cases we've found so far are either bugs that would have been found with ZERO_ALLOC_PTR or would have been perfectly fine with it, so I don't think anybody really _is_ that insane in the kernel) Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/