3 ms·

> standard library is allowed to do stuff normal libraries are not allowed to do. How does this work, given that it's still written in C++? Is there special ca

by Inityx 7y ago

> standard library is allowed to do stuff normal libraries are not allowed to do. How does this work, given that it's still written in C++? Is there special casing in the compiler to define the behavior?

chacham15 7y ago
Its about maintenance. Things which are "undefined behavior" can actually have a defined behavior if the compiler provides it. By doing something undefined in the stl, the compiler authors are saying that the compiler will support it and if the compiler changes, they authors will also change the library. If you rely on this behavior, theres no guarantee that the compiler wont change this behavior in a future update thereby breaking your code.
aidenn0 7y ago
It will only ever be compiled with clang, so as long as clang doesn't implement this behavior in a way that will cause it to be incorrect, that's fine. If it were to be special-cased, it would probably require an attribute or a pragma or something. While it's not unheard of for compilers to automatically detect they are compiling the standard library, it's fairly rare.
- deleted 7y ago
  [deleted]
- bregma 7y ago
  libc++ is compiled by compilers other than clang. It's a completely invalid assumption that it will only ever be compiled by clang, because it's never only over been compiled by clang. I say this as someone with a full time paid job supporting libc++ compiled by another compiler for a commercial organization in a safety context.
  - aidenn0 7y ago
    Oh, that's good to know. If obscure C++ compiler X were to cause incorrect behavior of this code, would it be easy to upstream the fix?
jlarocco 7y ago
Undefined behavior in C++ and C means that it's up to the implementor to decide what happens in a situation. Usually it ends up being whatever is most convenient or most performant on the target architecture. One consequence is that portable code can't depend on any particular behavior because it can be different between implementations. Every implementation will do something, but each one may do something completely different. Another consequence is that "undefined behavior" isn't undefined in the context of a specific implementation because you can look at what it does and see how it's defined in that implementation. In this case, libc++ is essentially part of the implementation, so it's fair game for it to depend on implementation details of clang.
- MaxBarraclough 7y ago
  > Undefined behavior in C++ and C means that it's up to the implementor to decide what happens in a situation > Every implementation will do something, but each one may do something completely different. If I'm reading this correctly, you're saying that we can depend on each compiler providing a consistent way of handling each kind of undefined behaviour. That's not correct. That describes implementation-defined behaviour, which is different. [0] Compilers do not have to decide what behaviour should result from a particular kind of undefined behaviour, and then commit to ensuring that behaviour occurs consistently. That's the point of undefined behaviour: the compiler is permitted to assume the absence of undefined behaviour, and to optimise accordingly. If you have undefined behaviour in your C++ code, you are not guaranteed to see consistent program behaviour. Your program is ill-formed. All bets are off, throughout the entire lifetime of your program. [1] (In C++, undefined behaviour can 'travel back in time', meaning that if your program invokes undefined behaviour, the behaviour across the entire lifetime of your program is made undefined.) A compiler may choose to commit to a certain behaviour for a certain type of undefined behaviour (such as guaranteeing wrap-around behaviour for signed overflow), but it is not required to. A compiler is required to define a consistent value for sizeof(int), because that's implementation-defined. [0] > Another consequence is that "undefined behavior" isn't undefined in the context of a specific implementation because you can look at what it does and see how it's defined in that implementation. This isn't right. Unless the compiler's documentation tells you that you can rely upon its handling of the relevant undefined behaviour, then then compiler is not required to provide consistent behaviour for any particular kind of undefined behaviour. > In this case, libc++ is essentially part of the implementation It's not, as it's not tied to one compiler. [2] [0] https://stackoverflow.com/a/4105123/ https://stackoverflow.com/a/4105123/ [1] https://stackoverflow.com/a/39915175/ https://stackoverflow.com/a/39915175/ [2] https://news.ycombinator.com/item?id=22202355 https://news.ycombinator.com/item?id=22202355

by Inityx 7y ago

chacham15 7y ago

Its about maintenance. Things which are "undefined behavior" can actually have a defined behavior if the compiler provides it. By doing something undefined in the stl, the compiler authors are saying that the compiler will support it and if the compiler changes, they authors will also change the library. If you rely on this behavior, theres no guarantee that the compiler wont change this behavior in a future update thereby breaking your code.

aidenn0 7y ago

It will only ever be compiled with clang, so as long as clang doesn't implement this behavior in a way that will cause it to be incorrect, that's fine. If it were to be special-cased, it would probably require an attribute or a pragma or something. While it's not unheard of for compilers to automatically detect they are compiling the standard library, it's fairly rare.

deleted 7y ago
[deleted]
bregma 7y ago
libc++ is compiled by compilers other than clang. It's a completely invalid assumption that it will only ever be compiled by clang, because it's never only over been compiled by clang. I say this as someone with a full time paid job supporting libc++ compiled by another compiler for a commercial organization in a safety context.
- aidenn0 7y ago
  Oh, that's good to know. If obscure C++ compiler X were to cause incorrect behavior of this code, would it be easy to upstream the fix?

jlarocco 7y ago

Undefined behavior in C++ and C means that it's up to the implementor to decide what happens in a situation. Usually it ends up being whatever is most convenient or most performant on the target architecture. One consequence is that portable code can't depend on any particular behavior because it can be different between implementations. Every implementation will do something, but each one may do something completely different. Another consequence is that "undefined behavior" isn't undefined in the context of a specific implementation because you can look at what it does and see how it's defined in that implementation. In this case, libc++ is essentially part of the implementation, so it's fair game for it to depend on implementation details of clang.

MaxBarraclough 7y ago
> Undefined behavior in C++ and C means that it's up to the implementor to decide what happens in a situation > Every implementation will do something, but each one may do something completely different. If I'm reading this correctly, you're saying that we can depend on each compiler providing a consistent way of handling each kind of undefined behaviour. That's not correct. That describes implementation-defined behaviour, which is different. [0] Compilers do not have to decide what behaviour should result from a particular kind of undefined behaviour, and then commit to ensuring that behaviour occurs consistently. That's the point of undefined behaviour: the compiler is permitted to assume the absence of undefined behaviour, and to optimise accordingly. If you have undefined behaviour in your C++ code, you are not guaranteed to see consistent program behaviour. Your program is ill-formed. All bets are off, throughout the entire lifetime of your program. [1] (In C++, undefined behaviour can 'travel back in time', meaning that if your program invokes undefined behaviour, the behaviour across the entire lifetime of your program is made undefined.) A compiler may choose to commit to a certain behaviour for a certain type of undefined behaviour (such as guaranteeing wrap-around behaviour for signed overflow), but it is not required to. A compiler is required to define a consistent value for sizeof(int), because that's implementation-defined. [0] > Another consequence is that "undefined behavior" isn't undefined in the context of a specific implementation because you can look at what it does and see how it's defined in that implementation. This isn't right. Unless the compiler's documentation tells you that you can rely upon its handling of the relevant undefined behaviour, then then compiler is not required to provide consistent behaviour for any particular kind of undefined behaviour. > In this case, libc++ is essentially part of the implementation It's not, as it's not tied to one compiler. [2] [0] https://stackoverflow.com/a/4105123/ https://stackoverflow.com/a/4105123/ [1] https://stackoverflow.com/a/39915175/ https://stackoverflow.com/a/39915175/ [2] https://news.ycombinator.com/item?id=22202355 https://news.ycombinator.com/item?id=22202355