I was referring to the fact that malloc(0) should run fine, without any errors. Turns out I indeed overlooked something, and really was writing the pointer returned, so please disregard my report.
Regards, Ákos On 14 March 2012 21:51, Guy Harris <g...@alum.mit.edu> wrote: > > On Mar 14, 2012, at 1:15 PM, Jakub Zawadzki wrote: > >> On Wed, Mar 14, 2012 at 09:01:07PM +0100, Akos Vandra wrote: >>> Figured it out, however this is a bug in wireshark, I suppose. >>> A call to ep_alloc(0) was the culprit. IMHO that should not be a >>> problem, as I expect it to work as malloc works, and malloc should >>> handle a 0 size, as stated in the C standard. >> >> In which way? It should return NULL (glib-like) or some not-NULL pointer >> (glibc-like)? >> AFAIR in C standard it's UB. > > Implementation-defined behavior. > > C90: > > If the size of the space requested is zero, the behavior is > implementation-defined, the value returned shall be either a null pointer or > a unique pointer. > > C99: > > If the size of the space requested is zero, the behavior is > implementation- defined: either a null pointer is returned, or the behavior > is as if the size were some nonzero value, except that the returned pointer > shall not be used to access an object. > > C99 makes it clearer that, as you note, you should *not* attempt to > dereference the pointer. > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> > Archives: http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
