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

Nicolas George george at nsup.org
Wed Mar 5 14:04:01 CET 2014


On 05.03.2014 00:03, Michael Niedermayer wrote:
> >are you sure that you arent overdesigning this ?

I know I am frequently annoyed by libraries that accept a pointer to a size
variable but do not use the same type as my code. If I can not change the
type of the variable in my code, I need to write something like:

	if (size > INT_MAX)
	    abort();
	int tmp_size = size;
	frobnicate(array, &tmp_size);
	size = tmp_size;

The worst offenders are, of course, the old libraries that use long
everywhere, but size_t vs int is a frequent annoyance too.

> >macros can confuse the "user", especially these kind of smart macros
> >that do tricks that C functions couldnt

There is no obligation to actually use the macro for anyone.

> >also the compiler
> >tends to produce more cryptic error messages when there are mistakes
> >in macro use than when there are mistakes in function use.

That is true, but I have noticed a significant enhancement in the recent
error messages, at least with gcc and clang.

Also, the macro would have the benefit of not type-pruning the pointers, and
therefore would be somewhat safer to use.


Le quintidi 15 ventôse, an CCXXII, Lukasz Marek a écrit :
> I assume you want whole function as a macro

I do not know what you mean exactly. A single macro to add an element to the
array is what I have in mind:

AV_DYNARRAY_ADD(size_t, SIZE_MAX, AVCodecContext *,
    array, size,
    array[size - 1] = new_element, /* if success */
    goto fail /* if failure */
    );

> This will also cause a lot of code duplication.

Object code duplication is not much of an issue, and this function is
actually rather small. The real problem is source code duplication, and it
happens less if the API is well designed.

> regarding sizeof(void *) == sizeof(intptr_t) it would be good to
> check it in standard, I had quick look and it is not defined, but

The standards that intptr_t is accurate enough so that void* -> intptr_t ->
void* can not drop information. In practice, that probably implies that
intptr_t is at least as large as a pointer, but it could be larger.

> the code exists for few years now, I believe there would be a
> problem already if it is not equal at some cases.

I doubt there is an architecture where it would be a problem, but
nonetheless it is an assumption that is not guaranteed. If it can be done
without it, that is better.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140305/097af6fe/attachment.asc>


More information about the ffmpeg-devel mailing list