Some fixes/improvements to libgst

>
>> On 30 Dec 2016, at 07:44, Lee Duhem <[hidden email]> wrote:
>>
>>
>
> Hi!
>
> sorry for the delay.
>
>
>> * byte.c (_gst_compile_bytecodes): Remove unnecessary copy.
>
> diff --git a/libgst/byte.c b/libgst/byte.c
> index 50ff07c..a90a139 100644
> --- a/libgst/byte.c
> +++ b/libgst/byte.c
> @@ -450,9 +450,6 @@ _gst_compile_bytecodes (gst_uchar * from,
>
>    if (free < (to - from))
>      {
> -      memcpy (_gst_cur_bytecodes->ptr, from, free);
> -      _gst_cur_bytecodes->ptr += free;
> -      from += free;
>        realloc_bytecodes (_gst_cur_bytecodes,
>                          BYTECODE_CHUNK_SIZE + (to - from));
>      }
>
> I think the delta is bigger than necessary? If you remove the
> advancing of from, then it should be applied to the delta too?
> What do you think?

>
>
>
>> * comp.c (_gst_compile_method): Protect new created `selector' from GC
>> properly.
>
> yes! makes sense
>
>> * gst-parse.c (expected): Call va_end.
>
> yes! at least according to the OSX manpage.
>
>
> will apply these two hunks

> The original logic is that if available space in _gst_cur_bytecodes is
> less than (to - from),
> it will copy part of contents from `from' to _gst_cur_bytecodes, then
> allocate more space
> through realloc_bytecodes(), and copy the rest from `from'.  However,
> the reallocation of
> _gst_cur_bytecodes may need to copy the content of it to the new location.
>
> And the new code will resize the capacity of _gst_cur_bytecodes first,
> then copy all the contents
> from `from' to it.  In this case, we may save one memcpy call, and
> some extra copying in
> realloc_bytecodes().

>
>> On 14 Jan 2017, at 12:27, Lee Duhem <[hidden email]> wrote:
>>
>
> Hi!
>
> another flight, another time to look at it. :)
>
>
>>>   if (free < (to - from))
>>>     {
>>> -      memcpy (_gst_cur_bytecodes->ptr, from, free);
>>> -      _gst_cur_bytecodes->ptr += free;
>>> -      from += free;
>>>       realloc_bytecodes (_gst_cur_bytecodes,
>>>                         BYTECODE_CHUNK_SIZE + (to - from));
>>>     }
>
>
>> The original logic is that if available space in _gst_cur_bytecodes is
>> less than (to - from),
>> it will copy part of contents from `from' to _gst_cur_bytecodes, then
>> allocate more space
>> through realloc_bytecodes(), and copy the rest from `from'.  However,
>> the reallocation of
>> _gst_cur_bytecodes may need to copy the content of it to the new location.
>>
>> And the new code will resize the capacity of _gst_cur_bytecodes first,
>> then copy all the contents
>> from `from' to it.  In this case, we may save one memcpy call, and
>> some extra copying in
>> realloc_bytecodes().
>
>
> Let's do the math now and compare it. My focus is on the from += free
> and my suspicion is that we now allocate more memory than before.
>
>
> free == 10
> from == 0
> to   == 20
> to-fr== 20
>
> Before:
> free < to-from          => true
> memcpy of 10 bytes
> from + free             = 10
> realloc CHUNK + 10      =
>
> After:
> free < to-from          => true
> realloc CHUNK + 20
>
>
> So I agree that the same data is written, ptr will be correct too but
> maybe a tiny bit more memory? What do you think?
>