[MPlayer-dev-eng] [PATCH] Fix building with Clang

[Brad Smith]

On 12/23/2021 2:55 PM, Reimar Döffinger wrote:

>
>> On 23 Dec 2021, at 15:57, Brad Smith <brad at comstyle.com> wrote:
>>
>> On 12/20/2021 10:47 AM, Reimar Döffinger wrote:
>>
>>>> On 10 Dec 2021, at 07:48, Brad Smith <brad at comstyle.com> wrote:
>>>>
>>>> Fix building with Clang.
>>>>
>>>>
>>>> ./stream/stream.h:322:46: error: invalid suffix on literal; C++11 requires a space between literal and identifier [-Wreserved-user-defined-literal]
>>>>   mp_dbg(MSGT_DEMUX, MSGL_DBG3, "seek to 0x%"PRIX64"\n", pos);
>>>>                                              ^
>>>>
>>>> ./stream/stream.h:326:49: error: invalid suffix on literal; C++11 requires a space between literal and identifier [-Wreserved-user-defined-literal]
>>>>            "Invalid seek to negative position %"PRIx64"!\n", pos);
>>> Sorry for the late reply, but I think this needs a bit more details/explanation.
>>> 1) I’ve quickly tested on macOS which uses clang and it has no issues, so this can’t be a problem with clang in general I think?
>>> 2) MPlayer is not C++11, in fact it is not C++ at all, so this messages does not really make sense. Sure it’s not a bug in clang, or maybe you used clang++ instead of clang as compiler?
>>>
>>> Now the change is not a big deal, it’s just that I am not a big fan of working around issues that are not properly understood, also because if it’s a real issue the commit message should make it clear how we can avoid re-introducing such issues in the future.
>> 1) Looks like you're not building with Live555 support.
> I did now, it makes no difference.
> Are you actually using it? Because MPlayer doesn't work with any version current enough to not be full of security issues I think...
> I had to use attached hack to make it just compile.
>
>> 2) Although almost all of MPlayer is C code there are two files in the tree that are C++ code.
> Why does it fail with your compilers when it seems to work with all the ones I have at hand?
> It seems the problem might be your compiler defaulting to C++11, and in the future even newer C++ versions.
> So the real issue might be that this old code really should be compiled with -std=c++98 if that option is available?
> After all your change might fix the issue with C++11 compatibility, but who knows what other issues would pop up if the compiler tried to compile it as C++30 or whatever...
> That said I don't know if there is a point in keeping these mp_dbg macros at all.

I don't know but this was commited back when we brought in Clang 6 and 
still is an issue with Clang 13. Clang all the way back to 6 defaults to 
C++14.

We had commited a number of similar diffs throughout our ports tree for 
these sorts of errors.

It looks like Clang handles this as an error by default. GCC handles 
this as a warning.

https://sourcecodeartisan.com/2021/03/06/invalid-suffix-on-literal.html

I see others mentioning these  sorts of issues with GCC back to 4.8..

https://bugzilla.mozilla.org/show_bug.cgi?id=865396