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 <guy@xxxxxxxxxxxx> 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@xxxxxxxxxxxxx>
> Archives: http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe