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

C considered dangerous

lwn.net

Post reply on HN
Print view View original

51–60 of 66 posts

Re: C considered dangerous

#51

Post by abainbridge »

xvilka wrote: post #38

Hopefully Zig [1] language will become a better alternative to C in upcoming years. Not talking about higher level code where Rust or Go can be a better choice. [1] https://ziglang.org/

The problem with Zig is that they changed almost everything. I think there's a high risk they introduced new design problems that we won't know about fully until Zig has been used in anger for 10 years.

I've always felt that C is near the sweet spot. I'd rather see a minimal change to C that broke backwards compatibility (because it has to) and fixed the top ten simple problems.

Re: C considered dangerous

#52

Post by pjmlp »

jcelerier wrote: post #44
pjmlp wrote: post #29

Earlier quoted context omitted.

Python, Erlang, Lua = Logic Errors C and C++ = Logic Errors + Memory Corruption + UB From this point of view, Σ Logic Errors < Σ (Logic Errors + Memory Corruption + UB)

hmmm... In my experience, I have had much less logic errors in C++ than in Python or JS because I tend to try to encode the domain logic into the types as much as possible, so that I can piggyback on the compiler.

And how many memory corruption and UB errors did your Python and JS code had?

Re: C considered dangerous

#53

Post by lomnakkus »

rwmj wrote: post #14
vardump wrote: post #8

Earlier quoted context omitted.

Perhaps because the memory buffers might be of different size. Maybe memcpy_oobp (out of bounds protection) signature could be: memcpy_oobp(void* dst, size_t dst_size, void* src, size_t src_size); Then again, I guess you could just as well do: memcpy(dst, src, min(dst_size, src_size)); But having to explicitly specify both destination and source sizes might have prevented a lot of buffer overwrite bugs.

I guess so. One of the LWN comments mentions a Microsoft function memcpy_s defined as: memcpy_s (void *dest, size_t destSize, const void *src, size_t count); which is effectively equivalent to your memcpy_oobp function. However the Microsoft function also returns an error code which must be checked (because count might be larger than destSize), thus providing another way for the programmer to screw up. I'm not sure i…

Using min() seems like it could be incredibly dangerous as an "implicit" behavior, not to mention surprising.

I'd wager it'd be much better to just specify that abort() gets called in the "overflow" case. (Given that overflow is basically never what you want anyway.)

Yeah, it'll crash but at least it won't be suprising/undefined behavior.

Re: C considered dangerous

#54

Post by rwmj »

lomnakkus wrote: post #53
rwmj wrote: post #14

Earlier quoted context omitted.

I guess so. One of the LWN comments mentions a Microsoft function memcpy_s defined as: memcpy_s (void *dest, size_t destSize, const void *src, size_t count); which is effectively equivalent to your memcpy_oobp function. However the Microsoft function also returns an error code which must be checked (because count might be larger than destSize), thus providing another way for the programmer to screw up. I'm not sure i…

Using min() seems like it could be incredibly dangerous as an "implicit" behavior, not to mention surprising. I'd wager it'd be much better to just specify that abort() gets called in the "overflow" case. (Given that overflow is basically never what you want anyway.) Yeah, it'll crash but at least it won't be suprising/undefined behavior.

For extra fun, the Microsoft implementation of memcpy_s returns an error instead of crashing if either of the pointers is NULL (thankfully doesn't apply if the copy size is 0). There's a reason I don't like writing software for Windows ...

Re: C considered dangerous

#55

Post by willtim »

millstone wrote: post #41
willtim wrote: post #7

Earlier quoted context omitted.

C actually gives one rather limited control over modern hardware with it's memory hierarchies and superscaler CPUs. Programming language research has also moved on a lot since the 70's, which is why we should be considering less dangerous languages (e.g. better type systems and less undefined behaviour). Languages like ATS and Rust also support explicit memory management, whilst being a whole lot safer.

Are you suggesting that other languages provide more control over modern hardware?

Yes. Currently access to modern hardware features are either via cumbersome APIs (e.g. NUMA, AVX intrinsics), handled via the OS (e.g. paging, scheduling), or handled via the hardware itself (cache memory hierarchy). The problem will get worse as modern CPUs and machines continue to diverge from those originally targetted by C in the 1970s.

Re: C considered dangerous

#56

Post by jcelerier »

pjmlp wrote: post #52
jcelerier wrote: post #44

Earlier quoted context omitted.

hmmm... In my experience, I have had much less logic errors in C++ than in Python or JS because I tend to try to encode the domain logic into the types as much as possible, so that I can piggyback on the compiler.

And how many memory corruption and UB errors did your Python and JS code had?

none, but I hardly ever encounter them in C++ too since I always develop in debug mode with sanitizers and debug std containers, so they blow up immediately. In C that's another story...

Re: C considered dangerous

#57

Post by pjmlp »

jcelerier wrote: post #56
pjmlp wrote: post #52

Earlier quoted context omitted.

And how many memory corruption and UB errors did your Python and JS code had?

none, but I hardly ever encounter them in C++ too since I always develop in debug mode with sanitizers and debug std containers, so they blow up immediately. In C that's another story...

So you are part of the 1% audience crowd from CppCon, developing software alone in C++ without any third party binary libs. :)

Re: C considered dangerous

#58

Post by pjmlp »

yason wrote: post #47

C is dangerous partly because assembly language is dangerous. We will always need some layer on top of assembly that is mostly unchecked and reflects back to how cpu instructions work. This is probably something we must live with until we have processors with the notion of type checking. C is dangerous partly because of swaths of undefined behaviour and loose typing. Eliminating much of undefined behaviour either by…

Ironically other systems programming languages developed outside AT&T walls since 1961 did not suffer from the majority of C's pain points regarding memory corruption.

I really wish Bell Labs had been allowed to sell UNIX.

Re: C considered dangerous

#59

Post by pjmlp »

willtim wrote: post #7
aogl wrote: post #3

Earlier quoted context omitted.

I agree, it's very click-baity. C is actually great and is only really dangerous because it gives the programmer so much control.

C actually gives one rather limited control over modern hardware with it's memory hierarchies and superscaler CPUs. Programming language research has also moved on a lot since the 70's, which is why we should be considering less dangerous languages (e.g. better type systems and less undefined behaviour). Languages like ATS and Rust also support explicit memory management, whilst being a whole lot safer.

Even in the 70's there was NEWP, PL/I, PL/S, PL/8, Concurrent Pascal, Mesa, BLISS, Modula-2, ....

C wins them all in implicit conversions and opportunities for memory corruption.

Their major sin was to be tied to commercial OSes, instead of one with source code available for a symbolic price to universities.

Re: C considered dangerous

#60

Post by pjmlp »

xvilka wrote: post #38

Hopefully Zig [1] language will become a better alternative to C in upcoming years. Not talking about higher level code where Rust or Go can be a better choice. [1] https://ziglang.org/

No language can become an alternative to C in the context of UNIX like OS because no one is going to re-write them from scratch, given their symbiotic nature.

Even if the complete userspace of Aix, HP-UX, *BSD, GNU/Linux, OS X, iOS, Solaris,.... gets re-writen in something else, there will always be the kernel written in C.

Hence why improving C's lack of safety is so important to get a proper IT stack.

Post reply on HN