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

C’s Biggest Mistake (2009)

digitalmars.com

Post reply on HN
Print view View original

271–280 of 382 posts

Re: C’s Biggest Mistake (2009)

#271

Post by Gene_Parmesan »

johnisgood wrote: post #184
saagarjha wrote: post #162

Earlier quoted context omitted.

Do they? Or are they just told that they should be using Rust? Even putting aside outdated curriculum, Rust is a fairly involved language to teach to a new programmer.

Indeed. What languages are most common in universities anyways? Haskell? Java? C++? OCaml? Which ones are the most common? Maybe he meant outside of the education system. I think the reason for that would be hype and peer pressure, and the feeling of novelty, with a hint of FOMO. I do not see any languages being pushed/hyped as hard as Rust.

My much younger brother is currently enrolled at a a major university in comp sci. His coursework is primarily in Java but with certain classes in C and other languages.

Re: C’s Biggest Mistake (2009)

#272

Post by saagarjha »

IshKebab wrote: post #259
baybal2 wrote: post #147

Earlier quoted context omitted.

> C code is being replaced by Rust fast. The only limit is how quickly programmers can become good at Rust. It's already happening. I think Rust has been very quickly fading into obscurity. What Rust hast brought to the tables was nearly the same what was brought by 100+ other programming languages in attempts to "fix C."

Oh... can you show me those 100+ other languages that have opt-out memory safety, explicit lifetime annotation, a borrow checker and no runtime?

That’s an extremely specific reading of the claim “fix C” that excludes almost everything but Rust.

Re: C’s Biggest Mistake (2009)

#273

Post by saagarjha »

knaq wrote: post #172
WalterBright wrote: post #30

Earlier quoted context omitted.

In my experience with language design, a little bit of syntactic sugar can have transformative results. C's function prototypes, syntactic sugar added circa 1990, were transformative for C programming.

C could have gained the safety of function prototypes without them. Note that the function bodies and call sites had the type information. It could have been propagated through the compiler and assembler to the linker, which would then check for compatibility. In some ways it would have worked much better. Header files can easily be wrong. The object files being linked are what really matter. So, suppose we decided t…

This would require storing type information in a symbol, would it not? Either via mangling or some other method.

Re: C’s Biggest Mistake (2009)

#274

Post by saagarjha »

pjmlp wrote: post #231
Koshkin wrote: post #66

Earlier quoted context omitted.

I wonder if a better idea (in principle) would be to have some kind of hardware implementation, sort of like a finer-grained memory segmentation.

Going forward Android will require hardware metadata extensions on ARM devices, as of Android 11.

You bring this up often and I ask you to modify your wording about every time I see it. Android will not require these extensions, no hardware ships with it yet. Android says they will support it.

Re: C’s Biggest Mistake (2009)

#275

Post by saagarjha »

jokoon wrote: post #244
WalterBright wrote: post #15

Author here. I'll be blunt and repeat a prediction I made 3 years ago or so: C is finished if it doesn't address the buffer overflow problem, and this proposal is a simple, easy, backwards compatible way to do it. It is simply too expensive to deal with buffer overflow bugs anymore. This one addition will revolutionize C programming like adding function prototypes did.

Do you think there are good contenders to replace C? V seems like it could.

V has a bit of a poor track record with its claims.

Re: C’s Biggest Mistake (2009)

#276

Post by saagarjha »

enriquto wrote: post #31
WalterBright wrote: post #15

Author here. I'll be blunt and repeat a prediction I made 3 years ago or so: C is finished if it doesn't address the buffer overflow problem, and this proposal is a simple, easy, backwards compatible way to do it. It is simply too expensive to deal with buffer overflow bugs anymore. This one addition will revolutionize C programming like adding function prototypes did.

The real troubles are undefined behavior and aliasing. Buffer overflows are just a well known gimmick of the language that is more or less controllable with some discipline. Aliasing is hell. You cannot even use a global variable safely!

> You cannot even use a global variable safely!

Sorry? I’m unsure what you mean here, because there are plenty of ways to use globals in ways I would call “safe”: no undefined behavior, correct output, …

Re: C’s Biggest Mistake (2009)

#277

Post by saagarjha »

xxpor wrote: post #37
enriquto wrote: post #31

Earlier quoted context omitted.

The real troubles are undefined behavior and aliasing. Buffer overflows are just a well known gimmick of the language that is more or less controllable with some discipline. Aliasing is hell. You cannot even use a global variable safely!

Isn't that what asan/ubsan is for? Granted, it's not static analysis, but it should catch most aliasing related errors, no?

Most, but not all. They are excellent tools but not perfect by any means.

Re: C’s Biggest Mistake (2009)

#278

Post by knaq »

saagarjha wrote: post #273
knaq wrote: post #172

Earlier quoted context omitted.

C could have gained the safety of function prototypes without them. Note that the function bodies and call sites had the type information. It could have been propagated through the compiler and assembler to the linker, which would then check for compatibility. In some ways it would have worked much better. Header files can easily be wrong. The object files being linked are what really matter. So, suppose we decided t…

This would require storing type information in a symbol, would it not? Either via mangling or some other method.

Yes. I proposed a method without mangling, but I suppose there isn't any reason why C couldn't use mangled names.

It also isn't a requirement that C++ use mangled names. Other ways of carrying the type information are possible. I like the idea of a reference to DWARF debug info, which C++ is already using to support stack unwinding for exceptions.

Re: C’s Biggest Mistake (2009)

#279

Post by saagarjha »

unsatchmo wrote: post #67
non-entity wrote: post #39

Earlier quoted context omitted.

As much as I dislike C > There are only two kinds of languages: the ones people complain about and the ones nobody uses. This unfortunately seems to mostly hold true.

Porque no los dos? There are a few languages that nobody uses and also everybody seems to complain about.

MUMPS.

Re: C’s Biggest Mistake (2009)

#280

Post by saagarjha »

knaq wrote: post #211
brundolf wrote: post #195

Earlier quoted context omitted.

Ok, but you didn't just say this should be possible, you said it should be the default best-practice . Even if it were useful in a handful of cases, this would be a terrible default way of doing things.

I didn't say it should be the default, but yes it should be. It is for structs. We can have giant structs. I've seen some over a megabyte in size. The default is that the callee gets a copy. (depending on the ABI it could be in the "wrong" stack frame, but it is a distinct copy) Are we having huge problems with structs being passed by value? I don't think so. Normal people pass pointers, except when they actually wan…

> Are we having huge problems with structs being passed by value?

Doing this frequently in any application means your profile will have a lot of memcpy in it.

Post reply on HN