[FFmpeg-devel] [PATCH] Remove only use of compound literals in FFmpeg.

[Clément Bœsch]

On Mon, Dec 30, 2013 at 08:28:13AM +0100, Reimar Döffinger wrote:
> On 30.12.2013, at 07:31, Clément Bœsch <u at pkh.me> wrote:
> > On Mon, Dec 30, 2013 at 01:09:17AM +0100, Nicolas George wrote:
> >> Le decadi 10 nivôse, an CCXXII, Reimar Döffinger a écrit :
> >>> However it still seems to be the only place where we use it?
> >> 
> >> I am afraid not: there is also the av_err2str() magic macro (in
> >> lavu/error.h), which is, if I say so myself, really convenient to use
> >> instead of the normal functions.
> >> 
> >> I suppose you could implement it using a static array, at the cost of 64
> >> extra bytes per use.
> 
> It can always be implemented as a local array with no disadvantage, it never does more than avoiding a local variable.

having a char buf[INCONSISTENT_SIZE] on top of a large function for an
label error at the end is a bit troublesome. Of course you can do it, but
    fprintf(stderr, "Error [%s]\n", av_err2str(ret));
is more cute than
    char buf[128];
    fprintf(stderr, "Error [%s]\n", av_make_error_string(buf, sizeof(buf), ret));

> In many cases it does less, since many compilers are unable to place them in .rodata and always build them on stack.
> 
> > Same goes for av_ts2str().
> 
> Is that function unused? I didn't notice it causing any issue.

Yes, in many place, and often in the same function call. To change that
you would need to declare like 4 or more "char bufN[64]", which sounds
like an expensive price for supporting a compiler no one uses anymore.

> I wonder if it's possibly related to e.g. no "const" or being used directly as a function call argument...
> I admit I expected to get 100s of errors like that, but strangely this file was the only one with issues...

-- 
Clément B.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20131230/17a8fb64/attachment.asc>