You just destroyed all C code in the world. At that level of paranoia, you've basically defined a brand new language, and if you're going to do that, why make it C at all?

Smart people with a ton of experience in C have already examined the possibility of defining a C dialect with much less undefined behavior in it. In fact, I believe it's been seriously tried more than once by independent groups. And the result has been the same each time; initial excitement and optimism gives way to total failure. It's simply way too deeply ingrained in the definition of C, backed by all the code in the world written in C. If you want less undefined behavior, your only choice is to leave C.

OP was talking about a compiler option, that most likely would not break anything unless you enable the flag.

As for choice, I'll take "here's what happens" vs "your code is in the hands of fate now" any day. Glad we do have choice.

I can't tell if this is satirical, but to be clear, you're proposing to disallow addition?

You could test whether overflow is going to happen first. Or use a math library that explicitly overflows with predictable results.

I know very few languages that do that. Even Rust doesn't when compiled for release. All for performance reasons.

Some additional points:

* It's not UB in Rust, it's guaranteed to be two's compliment overflow.

* It's still a "program error" and debug builds are required to panic.

* Non-debug builds are allowed to either panic or do the overflow, for performance reasons, as you mention. If it was feasible to always panic we'd do that; the current wording allows us to change it to do so in the future if it becomes feasible.

* If you want to do a checked add, you can, it's just not the default.

I might have lost the point in this long thread, but I'm pretty sure the suggestion was just to add it as an optional flag.

Rather define the behaviour of what happens when addition of two ints exceed the maximum allowed value.

You're changing your plan here. Maybe you could at least concede that the issue of UB is difficult and is not going to be solved by saying "why don't they just" on HN?

If the language does not prevent these mistakes from happening where it would be possible to do so, isn't the language at fault?

But you can't have your cake and eat it too. The language does not implement those checks because perhaps they're not so trivially implementable in the language.

Sure, rust is "safer" than C, but is it a better language? that's arguable.

> Sure, rust is "safer" than C, but is it a better language? that's arguable.

Obviously there are more aspects to a language than safety, so I'll give you that, but yes Rust is a better language than C in this aspect.

Don't forget that programming languages are meant for humans, not for computers. One of the primary goals of a programming language is to prevent humans from making dumb mistakes.

> One of the primary goals of a programming language is to prevent humans from making dumb mistakes.

That clearly wasn't the case when C was designed.

I'd wager that using C prevents large classes of errors that would be common place in assembly.

That said, colloquial history seems to say that there were plenty of languages which did a better job at that than C.

Only yesterday I implemented this in an application, although a bit simpler (is the user < n pixels from the bottom of the document? then render more heavy stuff) so yeah, that's a pretty recurrent use case for a library like that.

That only works for content that is statically (absolute) positioned?

I'm curious, is there a specific use case for using such a language today? Is it just legacy?

Mostly legacy.

The main application is decades old, and Providex provides a database of sorts, the language/runtime, a GUI toolkit, and the ability to run on windows, linux, and as a web app (you can use a "desktop" application written in providex in the browser, a great idea in principle, but with the cost of each user license of the language becomes cost prohibitive really fast).

So while everyone agrees that providex needs to go, that would mean replacing just about every single aspect of the company's core application GUI, language, database, even simple-ish things like the editor we use (which is built into the language) all need to be replaced. It's not an easy task.

We've started moving away, but it's going to take a lot of time, and a ton of effort. Right now we are still relying on the providex db stuff pretty much across the board (although i'm launching a new node.js+postgresql server in the next month or so), and we are slowly moving our hosted applications to more traditional web languages (we have some PHP, a bunch of javascript, and a little python).

But the language hurts. It is a combination of compiled and interpreted, so unless you jump through hoops files are saved in a binary format, and you can only use their editor. This also locks us into SVN as our source control, as it's the only VCS that providex supports (and even then, it's pretty bad support). There is virtually 0 tooling, nothing is open sourced, and it's really expensive. It's impossible to remove old code as there is 0 safety, any line can be GOTO'd or GOSUB'd by any other program at any time, and while new programs don't do that, the old programs that do are the ones that you want to refactor but can't. There are also programs where we are out of line numbers and need to resort to GOSUB "hacks" to add a line.

But it's not all bad. Being able to use a "drag and drop" visual editor to make a screen that will work on windows, linux, and the web is pretty nice, and having the DB so tightly coupled means stuff like upgrades/downgrades are pretty simple and don't involve multiple systems. It's also a pretty capable language all things considered (it has classes/objects, it's not as slow as i thought it would be, and it runs on anything without any modification).

For a long time it was still a useful teaching language. On how many languages can you simply make two statements and have a line drawn on the screen?

SCREEN 9

LINE (100,100)-(200,200)

I only know processing that has this kind of ease of use. But any curious kid, given a BASIC interpreter and the LINE instruction will start drawing stuff around, naturally come to loops, and so on, without having to worry about the details of "real" programming languages.