Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

What aspects do you consider "ultra-complex"? I agree that it has a very strange syntax, many features of it being unknown to most people; but besides that, it's as easy as Pascal, isn't it?


Pascal doesn't have half as UB as C, or possibilities to memory corruption.

Pascal here meaning compilers people actually use, not ISO Pascal from 1976, people love their C extensions after all.

A for C's simplicity, one just needs to organise a pub quiz, using ISO, and key extensions as source of inspiration.


When refering to Pascal, I mean something like Turbo, Vax or Apple Pascal, i.e. the version used at the height of popularity. Original Pascal has much less degrees of freedom. And I have no reason to assume that Turbo or Apple Pascal have less possibilities for memory corruption, or are better specified.


Starts by having proper strings and array types with bounds checking instead of pointers, followed by memory allocation with types instead of sizeof math, less scenarios for implicit conversions, reference parameters reducing the use cases where an invalid pointer might be used instead.


UB has nothing to do with complexity. In any case, from about 87 UB in the core language, we eliminated 15 in the last meeting, and already have concrete proposals for 10 more. C2Y will likely not have any trivial UB and hopefully also optional safety modes that eliminate the others.


It certainly has, as proven by recent talk at BlueHat 2024, on Windows kernel refactorings, as not everyone is knowledgeable of ISO C minutia and how optimisers take advantage of it, and still think they know better than analysers.


Maybe you can explain this better. People not knowing about footguns is also not the same complexity, it is just having footguns and people not knowing about them.


It is a matter of wording, doesn't change the trap is on the path.

Nonetheless, it is good to see efforts to reduce UB on the standard.

My complaints apply to C++ as well, naturally.


Just the integer promotion rules are more complex than many languages' entire parser. And undefined behaviour makes the language practically impossible to learn, because there's simply no way to confirm the answer to any question you have about the language (other than "submit a DR and wait a few years for the answer to be published" - even the people who wrote the standard are confidently wrong about what it says, all the time) - you can form a hypothesis about how the language works, write a program to test this hypothesis, observe that the result is what you thought it would be - and you've learnt nothing, because your program was almost certainly undefined behaviour under a strict enough reading of the standard.


I wasn't aware that it is that critical. I have been doing C projects of all sizes and on different platforms and with different toolchains for forty years, including many where the same code runs on different platforms and is built with different toolchains, and I have never come across an undefined behavior for which there was no practical work-around in reasonable time. I have also never seen a language specification that answers all questions, not even Pascal or Ada. I agree that implicit conversions are an unfortunate feature of C, but I think the same about all languages where you can easily assign floating point to integer variables (or vice versa), for example. Cross-toolchain and cross-platform experiments are a constant activity with all the programming languages I use.


> I have never come across an undefined behavior for which there was no practical work-around in reasonable time.

How would you know? You don't generally find out until a newer compiler release breaks your code.

> I have also never seen a language specification that answers all questions, not even Pascal or Ada.

Maybe, but I haven't see "upgrade your compiler, get a new security bug" be defended so aggressively in other languages. Probably more cultural than legalistic - obviously "the implementation is the spec" has its problems, but most languages commit to not breaking behaviour that most code relies on, even if that behaviour isn't actually written in the spec, which means that in practice the language (the social artifact) is possible to learn in a way that C isn't.

> I agree that implicit conversions are an unfortunate feature of C, but I think the same about all languages where you can easily assign floating point to integer variables (or vice versa), for example.

So don't use those languages either then?

> Cross-toolchain and cross-platform experiments are a constant activity with all the programming languages I use.

Sounds pretty unpleasant, I practically never need to do that.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: