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

11–20 of 114 posts

Re: Contracts for C

#11

Post by xboxnolifes »

HexDecOctBin wrote: post #7
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?

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

> People chose C because they liked C. Of course they don't want C to change.

The same thing can be said for every other language, yet they change.

Re: Contracts for C

#12

Post by integricho »

kstenerud wrote: post #10

I'm not sure I'm understanding this correctly... Given the examples, the author wants to ensure that 0 is not a possible input value, and NULL is not a possible output value. This could be achieved with a simple inline wrapper function that checks pre and post conditions and does abort() accordingly, without all of this extra ceremony But regardless of the mechansim you're left with another far more serious problem:…

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

Re: Contracts for C

#13

Post by ost-ing »

integricho wrote: post #12
kstenerud wrote: post #10

I'm not sure I'm understanding this correctly... Given the examples, the author wants to ensure that 0 is not a possible input value, and NULL is not a possible output value. This could be achieved with a simple inline wrapper function that checks pre and post conditions and does abort() accordingly, without all of this extra ceremony But regardless of the mechansim you're left with another far more serious problem:…

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

Re: Contracts for C

#14

Post by kstenerud »

integricho wrote: post #12
kstenerud wrote: post #10

I'm not sure I'm understanding this correctly... Given the examples, the author wants to ensure that 0 is not a possible input value, and NULL is not a possible output value. This could be achieved with a simple inline wrapper function that checks pre and post conditions and does abort() accordingly, without all of this extra ceremony But regardless of the mechansim you're left with another far more serious problem:…

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).

Nope. No error handling. No recovery. You crash. And ain't nothing you can do about it.

That's just bad design on top of the existing bad design. Things that crash your app are bad. No need to add even more.

Re: Contracts for C

#15

Post by OCTAGRAM »

__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?

Eiffel has unsolicited tracing garbage collection. For TGC-free programming there is Ada

Re: Contracts for C

#16

Post by brabel »

HexDecOctBin wrote: post #7
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?

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

This is funny because Java people say the same about Kotlin and Scala.

Re: Contracts for C

#17

Post by motorest »

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.

Re: Contracts for C

#18

Post by oguz-ismail »

xboxnolifes wrote: post #11
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#…

> People chose C because they liked C. Of course they don't want C to change. The same thing can be said for every other language, yet they change.

Well they shouldn't have. It was much more fun to program in Python 2.7 and Java 7, I wouldn't touch those languages with a five feet pole these days

Re: Contracts for C

#19

Post by lifthrasiir »

oguz-ismail wrote: post #18
xboxnolifes wrote: post #11

Earlier quoted context omitted.

> People chose C because they liked C. Of course they don't want C to change. The same thing can be said for every other language, yet they change.

Well they shouldn't have. It was much more fun to program in Python 2.7 and Java 7, I wouldn't touch those languages with a five feet pole these days

Why specifically Python 2.7 and not, like, 1.5? Python 1 and 2 are as different as 2 and 3 (that is, surprisingly not much).

Re: Contracts for C

#20

Post by lifthrasiir »

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…

C++ historically had much more implementations. It is probably more about the availability of quality compilers that are free to use and adapt, because even in C most new compilers for niche platforms are now based on GCC or clang for the practical reason.
Post reply on HN