4 ms·

Thanks for the context! You saved me from foolishly wandering into crowd-with-pitchforks mode.

• gpderetta 6y ago
  I was also reaching for my pitchfork, but in this case there is probably more code in the wild that relies on the (very useful) GCC extension as opposed to the standard behaviour.
  • hvdijk 6y ago
    I'm not too sure about the "more code in the wild" that would be broken though. GCC already disables this extension, in the cases where it conflicts with the standard, in -std=c++11 mode. I expect almost all code to either use -std=c++11 consistently, in which case it would already be broken with GCC, or to use -std=gnu++11 consistently, in which case it would continue to work with clang even after that patch. Chromium is weird in that it builds with -std=c++11 if building with clang, and it builds with -std=gnu++11 if building with GCC. (Change 11 to 14 or whatever else as needed.)
    • gpderetta 6y ago
      Thas clang distinguish between g++11 and c++11? If so chrome should probably use the former.
      • hvdijk 6y ago
        Yup, I made sure my change would make clang agree with GCC as far as this particular extension is concerned, so it was fully enabled in -std=gnu++11 mode and only enabled where it didn't conflict with standard C++ in -std=c++11 mode. I felt the same way that Chromium should just use the same flags for clang as for GCC if they want to keep using this extension, but they don't.
        • gpderetta 6y ago
          it seems that their reasoning is that they, understandably, do not want more gnu-ism in gnu++11 to creep up in their code base. But it seems that they are happy for this specific gnu-ism to creep up in other teams code bases... Odd at the very least.