Jamie Lokier <ja...@shareable.org> writes: > Ian Molton wrote: >> > Read the beginning of the thread. Basically it's for arrays, malloc(n * >> > sizeof(x)). >> >> well, make sure n is not 0. Its not that hard. I dont think I've *ever* >> had a situation where I wanted to pass 0 to malloc. > > I would like to remind everyone that sizeof(x) can be 0 too. For > example, on Linux sizeof(spinlock_t) == 0 on UP. Anything where you > have a bunch of structure fields which depend on compile time > configuration, or where a type might be replaced by a stub empty > structure, is a possible sizeof(x) == 0.
Therefore, outlawing qemu_malloc(0) impacts abstract data types: given some abstract type T, about which you're not supposed to assume anything, you can't do qemu_malloc(sizeof(T)). If anybody here is into outlawing scary zeroes, types with size zero looks like another one to outlaw. >> Its not that hard. > > The fact is there are a number of bugs in qemu where n == 0 is not > checked prior to calling qemu_malloc() at the moment. None of them > are "hard" to fix - they are rare cases that nobody noticed when > writing them. Hard or not so hard, what would "fixing" them buy us? I keep asking this question, no takers so far. > Until we have code analysis tools checking for that, bugs of that kind > will probably keep arising. Correct.
