@dysfun @david_chisnall Writing that down: „nobody can program c++“
I think it‘s beautiful. 😌
From the work we did on the de-facto C standard, I’m pretty sure no one can program C either. One of the things we did was send questions to compiler writers, members of the standards committee, and systems programmers. It was terrifying the number of questions that we set where:
- Standards-committee members said the language doesn’t guarantee the behaviour.
- GCC and Clang developers said that it was impossible to guarantee the behaviour in a vaguely performant implementation.
- Systems programmers said that the behaviour was absolutely critical and everything depended on it, and without it everything would break.
Everyone who uses C++ defines a subset to use. Everyone who uses C defines a superset to use.
@david_chisnall @dysfun Every standard and its implementations meet potholes, not just programming languages.
The complexity of the standard determines if this is somewhat manageable or a desaster.
C89 is what we use in #curl, sprinkled with some stuff from C99. We don‘t go beyond this and probably never will, because the cost/benefit does not justify it.
Our battlefield is platforms and interop with other implementations and dependencies.
@david_chisnall @dysfun We use pthreads for DNS resolving. Where would be the problem with that? Curious.
Prior to C11, there is no way of enforcing ordering of memory operations. The volatile keyword means that the compiler may not elide loads or stores to a specific object and may not reorder accesses to that object, but it may reorder any other memory access relative to that access.
This means that you cannot implement any of the pthread locking primitives in ISO C89. And no one did, they used GNU extensions, inline assembly (itself a vendor extension) or some combination of the two.
If you just use pthread locks (or equivalent), the calling code can be C89 if you’re careful. But there is no mechanism in the language’s abstract machine to prevent reordering across lock acquisition, you are relying on the fact that the compiler doesn’t look inside the lock and unlock calls and must assume that they may modify or read any memory location that it cannot prove is unaliased.
@david_chisnall @icing @dysfun Borrowing this quote for training materials I'm working on, I hope you don't mind
