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

21–30 of 114 posts

Re: Contracts for C

#21

Post by hdjrudni »

kstenerud wrote: post #14
integricho wrote: post #12

Earlier quoted context omitted.

Though is there a significant difference in which is more bad between running into undefined behavior and panic?

In C, sure. C is a dangerous language of its time. But these contracts don't make things better. Now you're removing control from the user. So now if an allocation fails, you crash. No way to recover from it. No getting an error signal back (NULL) so that you can say "OK, I need to clear up some memory and then try again". (Note that I'm not saying that inline error signaling such as NULL is good design - it's not).…

I'm not convinced. If something is going to cause a crash, like a nullptr, I'd rather crash near where the error happened with a nice error message, than hitting some UB crash god knows where.

Do I want my app to crash at all? No, of course not. If it's crashing, there's a serious bug. At least now I know where to look for it.

Should we pass back up an error signal instead of crashing? Yes, if it all possible, do that instead. Sometimes it's not possible or not worth the hassle for something you're 99.99999% sure can't/won't happen. Or literally can't currently happen, but you're afraid someone on the project might do a bad refactor at some point 5 years down the road and you want to guard against some weird invariant.

Re: Contracts for C

#22

Post by motorest »

nananana9 wrote: post #8
jimbob45 wrote: post #4

Earlier quoted context omitted.

Java 24 and C# 9 resemble little of their first versions. C++ might as well not even be the same language at this point. Why are we so conservative with C but then so happily liberal with every other language?

The complexity of C# and C++ should be a warning, not something to strive towards. C++ has 3 reasonable implementations, C has hundreds, for all sorts of platforms, where you don't get anything else. Most C developers don't want a modern C, they want a reliable C. WG14 should be pushing for clarifications on UB, the memory and threading model, documenting where implementations differ, and what parts of the language c…

> 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 criticized C++ for being a dead language and being too minimalistic and spartan.

> C++ has 3 reasonable implementations, C has hundreds, for all sorts of platforms, where you don't get anything else.

I don't understand what point you are trying to make. Go through the list of the most popular programming languages, and perhaps half of them are languages which only have a single implementation. What compelled you to criticize C++ for having at least 3 production-quality implementations?

> Most C developers don't want a modern C, they want a reliable C.

You speak only for yourself. Your personal opinion is based on survivorship bias.

I can tel you that as a matter of fact a key reason why the likes of Rust took off was that people working with low-level systems programming were desperate for a C with better developer experience and sane and usable standard library.

> Nobody really needs a new way to do asserts, case ranges, or a new way to write the word "NULL".

Again, you speak for yourself, and yourself alone. You believe you don't need new features. That's fine. But you speak for yourself.

Re: Contracts for C

#25

Post by arunc »

motorest wrote: post #17
WalterBright wrote: post #3

Digital Mars C++ has had contracts since, oh, the early 1990s? https://www.digitalmars.com/ctg/contract.html

> Digital Mars C++ has had contracts since, oh, the early 1990s? I think that implementations trying out their own experimental features is normal and expected. Ideally, standards would be pull-based instead of push-based. The real question is what prevented this feature from being proposed to the standardization committee.

It was proposed by Walter and denied by Stroustroup, probably to save C++. Karma hits back and he is trying to save C++ from Rust.

Re: Contracts for C

#26

Post by npoc »

motorest wrote: post #22
nananana9 wrote: post #8

Earlier quoted context omitted.

The complexity of C# and C++ should be a warning, not something to strive towards. C++ has 3 reasonable implementations, C has hundreds, for all sorts of platforms, where you don't get anything else. Most C developers don't want a modern C, they want a reliable C. WG14 should be pushing for clarifications on UB, the memory and threading model, documenting where implementations differ, and what parts of the language c…

> 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…

I agree. A lot of new additions to C++ make coding with it simpler, not more complex. However it does mean there's more to learn, because the old style of the language still exists and is still accepted by the modern compilers as opposed to say, Rust which removes replaced language features when it releases a new edition.

Re: Contracts for C

#27

Post by veltas »

sirwhinesalot wrote: post #24

Contracts getting proposed but still no slice/span type or even standardization of that new clang feature that makes f(int n, int a[n]) Actually do what it looks like it does. Sigh

You can do f(int n, int (*a)[n]) and it does what it looks like, since C99.

https://godbolt.org/z/8dfKMrGqv

Re: Contracts for C

#28

Post by miropalmu »

sirwhinesalot wrote: post #24

Contracts getting proposed but still no slice/span type or even standardization of that new clang feature that makes f(int n, int a[n]) Actually do what it looks like it does. Sigh

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

Re: Contracts for C

#29

Post by veltas »

__d wrote: post #2

I like Eiffel. But if I want to use Eiffel, I’ll use Eiffel (or Sather). I’d rather C remained C. Maybe that’s just me?

Truly I agree, but if we can add features to improve C codebases without rewriting them then that's a win, and you can just ignore them if you don't like them (as I will), but to the people where this has benefit they can be used.

Re: Contracts for C

#30

Post by AlotOfReading »

ost-ing wrote: post #13
integricho wrote: post #12

Earlier quoted context omitted.

Though is there a significant difference in which is more bad between running into undefined behavior and panic?

Exactly, panicking is a safer way to handle the situation rather than memory access violations

Safer in what sense? We have no idea whether this hypothetical code is in a userspace application that can exit safely at any time or a hard real time system where panicking could destroy hardware.

A lot of important programs (like the Linux kernel) don't operate strictly on the exact letter of the standard's UB semantics. They do things like add compiler flags to specify certain behaviors, or assume implementation details.

Post reply on HN