10 ms·

Nah that was mostly about extern "C" functions which technically can't throw (so the noexcept runtime stuff would be optimized out) but in practice there is a t

Nah that was mostly about extern "C" functions which technically can't throw (so the noexcept runtime stuff would be optimized out) but in practice there is a ton of code marked extern "C" which throws

dataflow 2y ago
extern "C" seems related to the other flags, not 'r'?
- terrymah 2y ago
  Well, yeah, things can be related to many things, but throwing extern "C"s was one of the motivations as I recall for 'r'. r is about a compiler optimization where we elide the runtime terminate check if we can statically "prove" a function can never throw. To prove it statically we depend on things like extern "C" functions not throwing, even though users can (and do) totally write that code.
Arech 2y ago
> in practice there is a ton of code marked extern "C" which throws Obviously, a random programmer could do any evil things, but does that apply to standard code, such as C standard library used from C++?
- leni536 2y ago
  Yes, qsort and bsearch can throw.
  - Arech 2y ago
    jfc... Can you give more info how did you learn this and to which lib implementation this applies?
    - tsimionescu 2y ago
      Well, given that qsort and bsearch take a function pointer and call it, that function pointer can easily point to a function that throws. So I think this applies to all implementations of qsort and bsearch. Especially since there is no way to mark a function pointer as noexcept.
      - leni536 2y ago
        > Especially since there is no way to mark a function pointer as noexcept. There is, noexcept is part of the type since C++17. In fact, I prefer noexcept function pointer parameters for C library wrappers, as I don't expect most libraries written in C to deal with stack unwinding at all.
        tsimionescu 2y ago
        Oops, you're right, I hadn't checked that this had changed in C++ 17.
    - leni536 2y ago
      https://eel.is/c++draft/alg.c.library#4 https://eel.is/c++draft/alg.c.library#4 Any library implementation that is C++ compliant must implement this. I'm pretty sure that libstdc++ + glibc is compliant, assuming sane glibc compiler options.
      - Arech 2y ago
        a perfect answer, thank you!
      - Arech 2y ago
        but to me these are - again - a user induced problems. I'm interested if a user doesn't do stupid things, should they still afraid that a standard extern C code could throw? Say, std::sprintf() which if I'm not mistaken boils down to C directly? Are there cases where C std lib could throw without a "help from a user"?

dataflow 2y ago

extern "C" seems related to the other flags, not 'r'?

terrymah 2y ago
Well, yeah, things can be related to many things, but throwing extern "C"s was one of the motivations as I recall for 'r'. r is about a compiler optimization where we elide the runtime terminate check if we can statically "prove" a function can never throw. To prove it statically we depend on things like extern "C" functions not throwing, even though users can (and do) totally write that code.

Arech 2y ago

> in practice there is a ton of code marked extern "C" which throws Obviously, a random programmer could do any evil things, but does that apply to standard code, such as C standard library used from C++?

leni536 2y ago
Yes, qsort and bsearch can throw.
- Arech 2y ago
  jfc... Can you give more info how did you learn this and to which lib implementation this applies?
  - tsimionescu 2y ago
    Well, given that qsort and bsearch take a function pointer and call it, that function pointer can easily point to a function that throws. So I think this applies to all implementations of qsort and bsearch. Especially since there is no way to mark a function pointer as noexcept.
    - leni536 2y ago
      > Especially since there is no way to mark a function pointer as noexcept. There is, noexcept is part of the type since C++17. In fact, I prefer noexcept function pointer parameters for C library wrappers, as I don't expect most libraries written in C to deal with stack unwinding at all.
      - tsimionescu 2y ago
        Oops, you're right, I hadn't checked that this had changed in C++ 17.
  - leni536 2y ago
    https://eel.is/c++draft/alg.c.library#4 https://eel.is/c++draft/alg.c.library#4 Any library implementation that is C++ compliant must implement this. I'm pretty sure that libstdc++ + glibc is compliant, assuming sane glibc compiler options.
    - Arech 2y ago
      a perfect answer, thank you!
    - Arech 2y ago
      but to me these are - again - a user induced problems. I'm interested if a user doesn't do stupid things, should they still afraid that a standard extern C code could throw? Say, std::sprintf() which if I'm not mistaken boils down to C directly? Are there cases where C std lib could throw without a "help from a user"?