Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Contracts for C

gustedt.wordpress.com

Post reply on HN
Print view View original

51–60 of 114 posts

Re: Contracts for C

#51

Post by 1718627440 »

babaceca wrote: post #50
1718627440 wrote: post #44

The author writes that contract_assume invokes undefined behaviour when the assertion fails: #define contract_assume(COND, ...) do { if (!(COND)) unreachable(); } while (false) But this means that the compiler is allowed to e.g. reorder the condition check and never output the message. (Or invoke nasal demons, of course). This doesn't make much sense. I get that you want the compiler to maybe do nothing different or…

There's no assertion required by spec. To the brain of a compiler writer UB means "the standard doesn't specify what should happen, therefore I can optimize with the assumption UB never happen." I disagree that this is how UB should be interpreted, but this fight is long lost. With that interpretation of UB, all `unreachable()` means is that the compiler is allowed to optimize as if this point in the code will never…

> so you can't rely on it as a runtime check.

Exactly. But we already have unreachable and assert. The whole point of contracts is, that they are checked by the compiler (when the compiler invoker asks for it).

Having the contract invoke UB in the fail case means that instead of replacing the error return with a diagnostic provable by the compiler, you replace the error return with potential corruption. In which case is that ever the right choice?

Re: Contracts for C

#52

Post by tempodox »

> Here unreacheable() is the new macro from C23 (and C++23) that makes the behaviour undefined whenever the branch of the invocation is reached.

I cannot, in good conscience, use a technology that adds even more undefined behavior. Instead it reinforces my drive to avoid C whenever I can and use OCaml or Rust instead.

Re: Contracts for C

#53

Post by pjmlp »

shakna wrote: post #49
motorest wrote: post #36

Earlier quoted context omitted.

> It was proposed by Walter and denied by Stroustroup, probably to save C++. Citation needed. For starters, where is the paper?

Well, there's this list Stroustrup offers, of systems in C++ that he would reject: [0] [0] https://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0...

One vote, C++ isn't a BDFL driven language.

Also WG14 famously killed Dennis Ritchie proposal to add fat pointers to C.

Language authors only have symbolic value once they relish control to a standards body.

Re: Contracts for C

#54

Post by 1718627440 »

tempodox wrote: post #52

> Here unreacheable() is the new macro from C23 (and C++23) that makes the behaviour undefined whenever the branch of the invocation is reached. I cannot, in good conscience, use a technology that adds even more undefined behavior. Instead it reinforces my drive to avoid C whenever I can and use OCaml or Rust instead.

I think it is good to explicitly invoke UB. It makes it much more obvious in the code, where it is intended and where not. It's a way to specify that this point in code is never reached, the code can't deal with it and I don't even care what the compiler does in this case.

It's also a good thing to tell the compiler that the programmer intends that this case will never happen, so that the static analyzer can point out ways through the code, where it actually does.

Re: Contracts for C

#55

Post by tpoacher »

One of the biggest problems I find with contracts whenever contracts are mentioned is that nobody seems to have a really clear definition of what exactly a contract 'is' or 'should be' (with the exception of languages where contracts are a formal part of the language, that is).

I find the general concept incredibly useful, and apply it in the more general sense to my own code, but there's always a bit of "what do I actually want contracts to mean / do here" back-and-forth before they're useful.

PS: I do like how D does contracts; though I admit I haven't used D much yet, to my great regret, so I can't offer my experience of how well contracts actually work in D.

Re: Contracts for C

#56

Post by TuxSH »

sirwhinesalot wrote: post #31
miropalmu wrote: post #28

Earlier quoted context omitted.

What do you mean no slice/span type? https://en.cppreference.com/w/cpp/container/span.html Or if you want multidimensional span: https://en.cppreference.com/w/cpp/container/mdspan.html

C, not C++. Also span had no bounds checking until the introduction of .at() in C++26, which was a very silly thing to do so late in an age where the white house was asking people to use memory safe languages.

> Also span had no bounds checking

While there was no reason not to have .at(), lack of bound checks by default isn't a bad thing, as inlined bound checks have the potential to highly pessimize code (esp. in loops); also standard library hardening is a thing.

IMO there's much more value to be had in migrating C code (and pre-C++11 code, too) to C++ (or Rust, depending on one's tastes); RAII - that is to say, the ability to automatically run destructors on scope exit - and in particular shared_ptr/unique_ptr/bespoke intrustive pointers drastically reduce the risks of use-after-free

Re: Contracts for C

#57

Post by motorest »

babaceca wrote: post #43
motorest wrote: post #22

Earlier quoted context omitted.

> The complexity of C# and C++ should be a warning, not something to strive towards. I think this talk about "complexity" is a red herring. C++ remains one of the most popular languages ever designed, and one of the key reasons is that since C++11 the standardization effort picked up steam and started including features that the developer community wanted and was eager to get. I still recall the time that randos crit…

The vast majority of C programmers will agree that they don't care for any of the new features, as is clearly evident by the fact that almost nobody elects to use the latest standards. The "most popular programming languages" are irrelevant here. C and C++ are standardized languages, and also the tools we use for code that actually matters. A standard that can't be implemented is worthless, and even the "3 high quali…

> The vast majority of C programmers will agree that they don't care for any of the new features,(...)

I think this belief is based on faulty assumptions, such as survivorship bias.

C++ became popular largely because it started off by extending C with the introduction of important features that the developer community wanted to use. The popularity of C++ over C attests how much developers wanted to add features to C.

C++ also started being used over C in domains where it was not an excellent fit, such as embedded programming, because the C community prefered to deal with C++'s higher cognitive load as an acceptable tradeoff to leverage important features missing from C.

The success of projects such as Rust and even Zig, Nim also comes at the expense of C's inability to improve the developer experience.

Not to mention the fact that some projects are still developed in C because of a mix of inertia and lack of framework support.

So to claim that the C programmers do not want change, first you need to ignore the vast majority that do want but already dropped C in favor of languages that weren't frozen in time.

It's also unbelievable to claim that a language that precedes the concept of developer experience represents the apex of language design. This belief lands somewhere between Stockholm syndrome and being mentally constrained to not look beyond a tool.

Re: Contracts for C

#58

Post by bmn__ »

tpoacher wrote: post #55

One of the biggest problems I find with contracts whenever contracts are mentioned is that nobody seems to have a really clear definition of what exactly a contract 'is' or 'should be' (with the exception of languages where contracts are a formal part of the language, that is). I find the general concept incredibly useful, and apply it in the more general sense to my own code, but there's always a bit of "what do I a…

No wonder it looks less than awesome to you. A contract is just a hack. Ideally, it should not exist because the type system already covers the programmer's intent. Languages that have shitty types which cannot express very much must work around the problem with contracts.

Re: Contracts for C

#59

Post by sarchertech »

pjmlp wrote: post #37
HexDecOctBin wrote: post #7

Earlier quoted context omitted.

People chose C because they liked C. Of course they don't want C to change. The only thing the ISO committee should be adding is stuff for filling in the holes in language (C23's Improved Tag Compatibility and __VA_OPT__ are good examples), not add features that were never part of C and were never supposed to be there. Your question can be reflected back to you: if you want an ever changing languages, go to Java, C#…

No, many people chose C, because they had to.

Yeah but those people are running it on some platform where it’s the only choice. And they are probably running a subset of C99. The likelihood of new features ever making it to those platforms is close to zero.

Re: Contracts for C

#60

Post by babaceca »

motorest wrote: post #57
babaceca wrote: post #43

Earlier quoted context omitted.

The vast majority of C programmers will agree that they don't care for any of the new features, as is clearly evident by the fact that almost nobody elects to use the latest standards. The "most popular programming languages" are irrelevant here. C and C++ are standardized languages, and also the tools we use for code that actually matters. A standard that can't be implemented is worthless, and even the "3 high quali…

> The vast majority of C programmers will agree that they don't care for any of the new features,(...) I think this belief is based on faulty assumptions, such as survivorship bias. C++ became popular largely because it started off by extending C with the introduction of important features that the developer community wanted to use. The popularity of C++ over C attests how much developers wanted to add features to C.…

> So to claim that the C programmers do not want change, first you need to ignore the vast majority that do want but already dropped C...

Good, we can ignore them. It's not a language for everybody, and if you're happily using C++, or Zig, or Nim, keep doing that.

Developer experience is a weigted sum of many variables. For you cool syntax features may play a huge role of that, for most C programmers a simple language with clear and understandable semantics is much more important.

There are many languages with cool syntax and shiny features, and very few of the latter kind. C belongs to the latter, and it also happens to be running a vast majority of the world's most important software.

You keep bringing up Rust as an example. It's probably the most famous of the new-age systems languages. If it's such a great language, when will we see a useful program written in it?

Post reply on HN