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

[Michael Niedermayer]

On Fri, Mar 21, 2014 at 01:26:28AM +0100, Lukasz Marek 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

"array data" ?


> so this can be replaced by something similar and (maybe) less misleading
> 
> intptr_t *tab = *(void**)tab_ptr;

void **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.

1. an array is allocated or reallocated
2. an element of intptr_t is written to it
3. the calling code accesses the field as some pointer type

the mix of intptr_t and some pointer type violate strict alissing


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
            conveniently.
New school: Use the highest level language in which the latest supercomputer
            can solve the problem without the user falling asleep waiting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140321/36d6cc1e/attachment.asc>