5 ms·

No, UB is allowed special powers for compiler and standard library implementors, which is what Herb Sutter means with internal behaviour. Meaning MSVC is aware

by pjmlp 3mo ago

No, UB is allowed special powers for compiler and standard library implementors, which is what Herb Sutter means with internal behaviour. Meaning MSVC is aware of these cases, so the compiler has special cases for it.

wavemode 3mo ago
GSL is not the standard library nor an internal runtime library. Its GitHub page claims that it supports a variety of compilers: > The GSL officially supports recent major versions of Visual Studio with both MSVC and LLVM, GCC, Clang, and XCode with Apple-Clang
- pjmlp 3mo ago
  It was originally created by Microsoft and as Herb mentions "all our target platforms", so most likely it gets special treatment.
  - Maxatar 3mo ago
    There is absolutely no special treatment afforded to the GSL by any of the target platforms. While we can't inspect MSVC's source code, both clang and GCC do not have any support or affordance for the GSL whatsoever and it would be very unusual to expect MSVC's source code to have some kind of affordance for this library.
    - achierius 3mo ago
      The 'special treatment' isn't technical, it's procedural -- insofar as if, during development for a new release, MSVC were to land some changes that broke GSL, Microsoft's testing would catch that and ensure that the changes were reverted or fixed to support the latter, prior to shipping. Since they're built as part of the same operating system, they can make sure not to step on one another's toes -- which is not a guarantee that they can make to third-party applications.
      - Maxatar 3mo ago
        I have no idea where you possibly got this idea from since the Github Issues tracker for GSL has numerous instances of new releases of MSVC breaking GSL compilation.
        ranger_danger 3mo ago
        I think they're saying that since they denote specific compiler versions as "officially supported", they can get away with saying the "UB" is not an issue in those versions only because they've already tested its behavior there, and anything else you compile with is untested and unsupported 'here be dragons' land. You may wish they target every possible compiler brand and version, but they are free to disagree with you and only "support" specific ones. Unfortunately this also has the same effect as the Linux kernel now in that it is no longer technically compliant with any C++ (or C) standard.
        Maxatar 3mo ago
        How does a library writer testing that their library works with a specific version of a compiler that was already released have anything to do with a compiler implementation providing special treatment for that library? Your interpretation contradicts the statement that "during development for a new release, MSVC were to land some changes that broke GSL, Microsoft's testing would catch that and ensure that the changes were reverted or fixed to support the latter, prior to shipping."
        ranger_danger 3mo ago
        > How does a library writer testing that their library works with a specific version of a compiler that was already released have anything to do with a compiler implementation providing special treatment for that library? Not special treatment for the library, but the library being able to assume that specific UB handling in certain existing compiler versions exists, can be relied on, and is compatible with the library's assumptions of such behavior, as long as those are the only versions they officially "support."
digitalPhonix 3mo ago
That's my point - GSL is NOT MSVC only, it's a general purpose library and NOT a standard library implementation of a toolchain so any compiler is expected to be able to compile it (it also explicitly targets clang & gcc).
- pjmlp 3mo ago
  It was originally created by Microsoft and as Herb mentions "all our target platforms", so most likely it gets special treatment.
  - aw1621107 3mo ago
    At the time Herb made that comment GSL was documented as supporting XCode 12.5.1/13.2.1, GCC 10/11, Clang 11/12, and Visual Studio 2019/2022 using both MSVC/LLVM [0]. Even if MSVC had special support for GSL I'm a bit more skeptical that such support would extend to XCode, GCC, and Clang. [0]: https://github.com/microsoft/GSL/tree/99a29ce797c8337b8923f2688ba1489be6f65bc4 https://github.com/microsoft/GSL/tree/99a29ce797c8337b8923f2...
20k 3mo ago
Clang is a target for the GSL though. How can MSVC's special powers prevent this from being exploitable UB in Clang/LLVM? This code boils down to static_cast<int>(some_double); so nothing fancy is going on here
- pjmlp 3mo ago
  Actually Microsoft has their own fork that ships with Visual Studio installer. However that was me guessing from Herb Sutter's reply.
  - rhinocnc 3mo ago
    yes, that is right

by pjmlp 3mo ago

wavemode 3mo ago

GSL is not the standard library nor an internal runtime library. Its GitHub page claims that it supports a variety of compilers: > The GSL officially supports recent major versions of Visual Studio with both MSVC and LLVM, GCC, Clang, and XCode with Apple-Clang

pjmlp 3mo ago
It was originally created by Microsoft and as Herb mentions "all our target platforms", so most likely it gets special treatment.
- Maxatar 3mo ago
  There is absolutely no special treatment afforded to the GSL by any of the target platforms. While we can't inspect MSVC's source code, both clang and GCC do not have any support or affordance for the GSL whatsoever and it would be very unusual to expect MSVC's source code to have some kind of affordance for this library.
  - achierius 3mo ago
    The 'special treatment' isn't technical, it's procedural -- insofar as if, during development for a new release, MSVC were to land some changes that broke GSL, Microsoft's testing would catch that and ensure that the changes were reverted or fixed to support the latter, prior to shipping. Since they're built as part of the same operating system, they can make sure not to step on one another's toes -- which is not a guarantee that they can make to third-party applications.
    - Maxatar 3mo ago
      I have no idea where you possibly got this idea from since the Github Issues tracker for GSL has numerous instances of new releases of MSVC breaking GSL compilation.
      - ranger_danger 3mo ago
        I think they're saying that since they denote specific compiler versions as "officially supported", they can get away with saying the "UB" is not an issue in those versions only because they've already tested its behavior there, and anything else you compile with is untested and unsupported 'here be dragons' land. You may wish they target every possible compiler brand and version, but they are free to disagree with you and only "support" specific ones. Unfortunately this also has the same effect as the Linux kernel now in that it is no longer technically compliant with any C++ (or C) standard.
        Maxatar 3mo ago
        How does a library writer testing that their library works with a specific version of a compiler that was already released have anything to do with a compiler implementation providing special treatment for that library? Your interpretation contradicts the statement that "during development for a new release, MSVC were to land some changes that broke GSL, Microsoft's testing would catch that and ensure that the changes were reverted or fixed to support the latter, prior to shipping."
        ranger_danger 3mo ago
        > How does a library writer testing that their library works with a specific version of a compiler that was already released have anything to do with a compiler implementation providing special treatment for that library? Not special treatment for the library, but the library being able to assume that specific UB handling in certain existing compiler versions exists, can be relied on, and is compatible with the library's assumptions of such behavior, as long as those are the only versions they officially "support."

digitalPhonix 3mo ago

That's my point - GSL is NOT MSVC only, it's a general purpose library and NOT a standard library implementation of a toolchain so any compiler is expected to be able to compile it (it also explicitly targets clang & gcc).

pjmlp 3mo ago
It was originally created by Microsoft and as Herb mentions "all our target platforms", so most likely it gets special treatment.
- aw1621107 3mo ago
  At the time Herb made that comment GSL was documented as supporting XCode 12.5.1/13.2.1, GCC 10/11, Clang 11/12, and Visual Studio 2019/2022 using both MSVC/LLVM [0]. Even if MSVC had special support for GSL I'm a bit more skeptical that such support would extend to XCode, GCC, and Clang. [0]: https://github.com/microsoft/GSL/tree/99a29ce797c8337b8923f2688ba1489be6f65bc4 https://github.com/microsoft/GSL/tree/99a29ce797c8337b8923f2...

20k 3mo ago

Clang is a target for the GSL though. How can MSVC's special powers prevent this from being exploitable UB in Clang/LLVM? This code boils down to static_cast<int>(some_double); so nothing fancy is going on here

pjmlp 3mo ago
Actually Microsoft has their own fork that ships with Visual Studio installer. However that was me guessing from Herb Sutter's reply.
- rhinocnc 3mo ago
  yes, that is right