[FFmpeg-devel] [PATCH 1/4] lavu: add simple array implementation

[Lukasz Marek]

On 21.03.2014 01:43, wm4 wrote:
> On Fri, 21 Mar 2014 01:26:28 +0100
> Lukasz Marek <lukasz.m.luki2 at gmail.com> wrote:
>
>> On 21.03.2014 00:03, Michael Niedermayer wrote:
>>> On Thu, Mar 20, 2014 at 10:44:41PM +0100, Lukasz Marek wrote:
>>>>>>    mem.c |   13 +++++++++++++
>>>>>>    mem.h |   19 +++++++++++++++++--
>>>>>>    2 files changed, 30 insertions(+), 2 deletions(-)
>>>>>> 7fad1be9083fcaef4435fa0273f79bceca98821b  0001-lavu-mem-add-av_dynarray_add_nofree-function.patch
>>>>>>   From 4cadb3328ba018b37c5dfe05a637b50a262151c6 Mon Sep 17 00:00:00 2001
>>>>>> From: Lukasz Marek <lukasz.m.luki at gmail.com>
>>>>>> Date: Tue, 25 Feb 2014 01:06:06 +0100
>>>>>> Subject: [PATCH] lavu/mem: add av_dynarray_add_nofree function
>>>>>>
>>>>>> av_dynarray_add_nofree function have similar functionality
>>>>>> as existing av_dynarray_add, but it doesn't deallocate memory
>>>>>> on fails.
>>>>>>
>>>>>> TODO: minor bump and update doc/APIChanges
>>>>>>
>>>>>> Signed-off-by: Lukasz Marek <lukasz.m.luki at gmail.com>
>>>>>> ---
>>>>>>    libavutil/mem.c |   13 +++++++++++++
>>>>>>    libavutil/mem.h |   19 +++++++++++++++++--
>>>>>>    2 files changed, 30 insertions(+), 2 deletions(-)
>>>>>>
>>>>>> diff --git a/libavutil/mem.c b/libavutil/mem.c
>>>>>> index 7206ddc..b9b5742 100644
>>>>>> --- a/libavutil/mem.c
>>>>>> +++ b/libavutil/mem.c
>>>>>> @@ -278,6 +278,19 @@ void *av_memdup(const void *p, size_t size)
>>>>>>        return ptr;
>>>>>>    }
>>>>>>
>>>>>> +int av_dynarray_add_nofree(void *tab_ptr, int *nb_ptr, void *elem)
>>>>>> +{
>>>>>
>>>>>> +    intptr_t *tab = *(intptr_t**)tab_ptr;
>>>>>
>>>>> undefined behavior (strict aliasing violation)
>>>>
>>>>
>>>> Can you tell how it is wrong?
>>>
>>> yes sure
>>>
>>> quoting the spec:
>>>
>>> 7 An object shall have its stored value accessed only by an lvalue expression that has one of
>>>     the following types:76)
>>>     - a type compatible with the effective type of the object,
>>>     - a qualified version of a type compatible with the effective type of the object,
>>>     - a type that is the signed or unsigned type corresponding to the effective type of the
>>>         object,
>>>     - a type that is the signed or unsigned type corresponding to a qualified version of the
>>>         effective type of the object,
>>>     - an aggregate or union type that includes one of the aforementioned types among its
>>>         members (including, recursively, a member of a subaggregate or contained union), or
>>>     - a character type.
>>>
>>>
>>> i dont think intptr_t and some pointer are compatible types
>>> but maybe iam missing something
>>
>> tab_ptr is pointer to pointer to array data
>> so this can be replaced by something similar and (maybe) less misleading
>>
>> intptr_t *tab = *(void**)tab_ptr;
>>
>> This line is copied from Nicolas implementation/original implementation.
>>
>> Still don't know what strict aliasing have anything to do here.
>
> This is simply undefined behavior according to C. Basically, you can't
> derference a pointer that was casted from a different pointer type.
> Unless one of the exceptions applies (like unions or char*).
>
> So, this is not legal:
>
> 	struct foo *foo_ptr;
> 	void *void_ptr = foo_ptr;
> 	*(void **)void_ptr = NULL;

Is this also disallowed?:

foo *foo_ptr;
void *tab_ptr = &foo_ptr;
*(intptr_t **)tab_ptr = NULL;

As I said function takes void* but it is in fact void**

> unless Michael and me are interpreting the standard incorrectly.

I don't say you are not right, but seems strange.