Development quote of the week
Development quote of the week
Posted Dec 1, 2022 22:47 UTC (Thu) by Wol (subscriber, #4433)In reply to: Development quote of the week by Karellen
Parent article: Development quote of the week
In other words, C IS NO LONGER FIT FOR SYSTEMS PROGRAMMING.
I don't remember if it was you, but when someone said "you need to program to the C model, not the hardware model", that is the death knell of a systems programming language. If you're not allowed to program to the hardware, why the hell are you using it to control said hardware?
> undefined behavior
> behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements
Note this explicitly includes "A NONPORTABLE CONSTRUCT", ie valid code that is not guaranteed to work across divergent systems. In practice, what the compiler writers are doing is saying "there is no such thing as nonportable constructs", despite the standard explicitly allowing for it. Unfortunately, a systems programming language absolutely requires non-portable constructs that can be trusted to work ...
Cheers,
Wol
Posted Dec 1, 2022 22:55 UTC (Thu)
by pizza (subscriber, #46)
[Link] (1 responses)
By that definition, the only acceptable programming language for systems programming is... bare assembly.
Posted Dec 2, 2022 0:41 UTC (Fri)
by khim (subscriber, #9252)
[Link]
Indeed. The only theoretical way to create low-level language without UB would be to employ Coq to ask developers to provide proofs of correctness for their programs. Then there wouldn't be UB because you would be, quite literally, forbidden from doing things which cause UB (in particular any program which produces integer overflow wouldn't be able to do that because it would be compile-time error to write such program). Surprisingly enough this world as not as far from us as we may imagine, there are already attempts to employ such techniques to practical tasks. But it's not even remotely close to “programming for the hardware” model. Rust's solution to this dilemma is just to go and kick people who don't understand that out of the community. But I don't think C and/or C++ can really do that. Old hats feel they are entitled to be able “to program for the hardware” model and even people who understand why UBs are unavoidable are getting tired. It's one thing to write small amount of UB-capable code in the Rust's
Posted Dec 1, 2022 23:06 UTC (Thu)
by Karellen (subscriber, #67644)
[Link]
Yeah, if by "no longer" you mean "since it was first standardised in 1989". Because that's when UB was defined and its semantics decided upon. Not quite. In practice, (modern) compiler writers allow for non-portable constructs, but you have to explicitly opt into them. (If they make sense on the platform you are compiling for. Which they might not, because they're non-portable). Hence GCC's -fwrapv and -fno-delete-null-pointer-checks.
Development quote of the week
> By that definition, the only acceptable programming language for systems programming is... bare assembly.
Development quote of the week
unsafe blocks, it's entirely different things if you need to think about these hundreds of possible UBs all the time when you write each and every line of code.Development quote of the week
C IS NO LONGER FIT FOR SYSTEMS PROGRAMMING.
In practice, what the compiler writers are doing is saying "there is no such thing as nonportable constructs", despite the standard explicitly allowing for it.