On 12/05/2009 07:08 PM, malc wrote:
What's the impact of such usage? What would improve for users if it were eradicated? For developers? I believe the answer the first two questions is "nothing in particular", and the answer to the last one is "hassle". But I'd be happy to see *specific* examples (code, not hand-waving) for where I'm wrong. I'm opposed to "fixing" something without a real gain, not just because it's work, but also because like any change it's going to introduce new bugs. I'm particularly critical of outlawing zero size for uses like malloc(N*sizeof(T). These are fairly common in our code. Having to add special treatment for N==0 is a trap for the unwary. Which means we'll never be done chasing this stuff. Moreover, the special treatment clutters the code, and requiring it without a clear benefit is silly. Show me the benefit, and I'll happily reconsider. For a specific example, let's look at the first example from my commit message again: load_elf32(), load_elf64() in hw/elf_ops.h. "Fix" for its "broken" usage of qemu_mallocz(), shot from the hip, entirely untested:Excellent example, now consider this: read$ cat<< eof | gcc -x c - #define _GNU_SOURCE #include<err.h> #include<unistd.h> #include<stdlib.h> #include<fcntl.h> int main (void) { int fd = open ("/dev/zero", 0); int ret; void *p = (void *) -1; if (fd == -1) err (1, "open"); ret = read (fd, p, 0); if (ret != 0) err (1, "read"); return 0; } eof read$ ./a.out a.out: read: Bad address
I don't see how this is relevant. Linux' read(2) may or may not be broken, but what does that have to do with breaking callers of qemu_malloc() for certain use cases?
-- Do not meddle in the internals of kernels, for they are subtle and quick to panic.
