r224887 avoids relying on implementation-defined behavior (multichar constants). We don't want to roll out that commit. But it also breaks the build with GCC 5. We'd like to continue supporting GCC 5 in trunk for another half a year, as per https://trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy. This is actually pretty difficult and messy, but I think I have a solution that works for GCC 5 without sacrificing Jer's nice constexpr constructor when using newer compilers.
Created attachment 327037 [details] Patch
Alternatively, would it be possible to add a no-argument constructor that initializes to zero? FourCC { 0 } would still be broken, but the alternative would be less ugly.
Comment on attachment 327037 [details] Patch Jer .. any opinion on this? I will r+ it tomorrow if there isn't concern about this patch. Its a build fix, so it has a bit of urgency.
(In reply to Ms2ger from comment #2) > Alternatively, would it be possible to add a no-argument constructor that > initializes to zero? FourCC { 0 } would still be broken, but the alternative > would be less ugly. Seems like a good idea. Let's see what Jer thinks before I spend more time on this, though, because this was harder than it looks and I don't care to admit how much time I spent on it. :P
Comment on attachment 327037 [details] Patch This looks fine.
(In reply to Ms2ger from comment #2) > Alternatively, would it be possible to add a no-argument constructor that > initializes to zero? FourCC { 0 } would still be broken, but the alternative > would be less ugly. Although it's ugly, I decided to stick with the current approach to avoid needing to define the no-argument constructor in the non-GCC 5 case. This way, when we delete the fallback code, we won't have the extra constructor left over.
Comment on attachment 327037 [details] Patch Clearing flags on attachment: 327037 Committed r224937: <https://trac.webkit.org/changeset/224937>
All reviewed patches have been landed. Closing bug.
<rdar://problem/35600883>