[FFmpeg-devel] compound literal in public header file

[Tobias Rapp]

On 16.05.2018 11:27, Tomas Härdin wrote:
> ons 2018-05-16 klockan 11:16 +0200 skrev Tobias Rapp:
>> On 16.05.2018 10:29, Tomas Härdin wrote:
>>> ons 2018-05-16 klockan 10:18 +0800 skrev Zhao Zhili:
>>>> The av_err2str macro in libavutil/error.h use compound literal:
>>>>
>>>> #define av_err2str(errnum) \
>>>>        av_make_error_string((char[AV_ERROR_MAX_STRING_SIZE]){0},
>>>> AV_ERROR_MAX_STRING_SIZE, errnum)
>>>>
>>>> C++ compiler may not support it or treat the usage as invalid.
>>>> For example, g++ 5.4 raise an error: taking address of temporary
>>>> array.
>>>>
>>>> 1. Should the macro be defined for C only?
>>>> 2. Or make it as valid C++? (I don't know how to do that)
>>>
>>> First of all, this shouldn't matter since av_err2str is not actually
>>> used in any header. libavutil/timer.h makes use of it in another macro,
>>> so that also doesn't matter.
>>>
>>> Second, libavutil is a C library, not a C++ library. However, it might
>>> be nicer to make that a static inline function, if possible. Or move it
>>> to an internal header, since it doesn't look like something that should
>>> be exposed as part of the public API.
>>
>> ffmpeg.c/ffprobe.c is using it for assembling log messages and I'm using
>> it in my private tools, too. As it is a convenient utility function I
>> would prefer to keep it in the public headers of libavutil.
> 
> ffmpeg.c/ffprobe.c are C.. :)
> 
> If you're in C++, why don't you just write your own variant that
> returns std::string?

Yes, I am referring to usage of the libavutil headers in C. If the macro 
is only hidden for C++ and available in C, that would be OK for me. But 
if the static inline function variant would support both C and C++, this 
would look like a solution where C++ users are not forced to implement a 
more "integrated" replacement but of course have the option to do so.

Regards,
Tobias