malc <av1...@comtv.ru> writes: > On Sun, 6 Dec 2009, Markus Armbruster wrote: > >> malc <av1...@comtv.ru> writes: >> >> > On Sat, 5 Dec 2009, Markus Armbruster wrote: >> > >> >> Anthony Liguori <anth...@codemonkey.ws> writes: >> >> >> >> > Markus Armbruster wrote: >> >> >> Commit a7d27b53 made zero-sized allocations a fatal error, deviating >> >> >> from ISO C's malloc() & friends. Revert that, but take care never to >> >> >> return a null pointer, like malloc() & friends may do (it's >> >> >> implementation defined), because that's another source of bugs. >> >> >> >> >> >> Rationale: while zero-sized allocations might occasionally be a sign of >> >> >> something going wrong, they can also be perfectly legitimate. The >> >> >> change broke such legitimate uses. We've found and "fixed" at least >> >> >> one >> >> >> of them already (commit eb0b64f7, also reverted by this patch), and >> >> >> another one just popped up: the change broke qcow2 images with virtual >> >> >> disk size zero, i.e. images that don't hold real data but only VM state >> >> >> of snapshots. >> >> >> >> >> > > > [..snip..] > > >> > >> > P.S. It would be interesting to know how this code behaves under OpenBSD, >> > with >> > p = malloc (0); [...] >> >> Replace "p = (void *)-1" by "p = NULL" and it works just fine. >> > > That's why i asked for somone to run it on OpenBSD: > > Quoting > http://www.openbsd.org/cgi-bin/man.cgi?query=malloc&apropos=0&sektion=3&manpath=OpenBSD+Current&arch=i386&format=html > > Allocation of a zero size object returns a pointer to a zero size object. > This zero size object is access protected, so any access to it will gen- > erate an exception (SIGSEGV). Many zero-sized objects can be placed con- > secutively in shared protected pages. The minimum size of the protection > on each object is suitably aligned and sized as previously stated, but > the protection may extend further depending on where in a protected zone > the object lands.
read(fd, malloc(0), 0) is just fine, because read() doesn't touch the buffer when the size is zero. >> malloc() either returns a valid pointer or NULL, so what read() does for >> other pointers doesn't matter. > > Replace "returns" with "should" and this still won't match the wording > of the standard, besides as "read" behaviour on Linux shows following > those are not high on the agenda. > > 7.20.3.3 The malloc function > > Synopsis > > [#1] > > #include <stdlib.h> > void *malloc(size_t size); > > Description > > [#2] The malloc function allocates space for an object whose > size is specified by size and whose value is indeterminate. > > Returns > > [#3] The malloc function returns either a null pointer or a > pointer to the allocated space. > > I don't know what a "valid pointer" in this context represents. I can talk standardese, if you prefer :) malloc() either returns either a null pointer or a pointer to the allocated space. In either case, you must not dereference the pointer. OpenBSD chooses to return a pointer to the allocated space. It chooses to catch common ways to dereference the pointer. Your "p = (void *)-1" is neither a null pointer nor can it point to allocated space on your particular system. Hence, it cannot be a value of malloc() for any argument, and therefore what read() does with it on that particular system doesn't matter.
