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

61–66 of 66 posts

Re: C considered dangerous

#61

Post by notacoward »

vardump wrote: post #18
yaris wrote: post #10

Earlier quoted context omitted.

Well, I can say the same about Python, Erlang, Lua, in addition to C and C++. I believe C is not worse than these languages, only that C requires different (sometimes very different) skills and discipline.

I'm absolutely sure same skill level programmer will create less defects in Python, Erlang and Lua than in C. You really have to try to overwrite memory in those languages. Of course you can shoot yourself into foot with stuff like metatables in Lua and Python metaclasses and whatnot. Then again you should see some C macro messes around... Anyways I don't like when people defend C with that age old argument it requir…

> I'm absolutely sure same skill level programmer will create less defects in Python, Erlang and Lua than in C.

Fewer defects, or just different (arguably less severe) defects? It's great that you're sure, but evidence would be even better.

Re: C considered dangerous

#62

Post by FraKtus »

pjmlp wrote: post #26
FraKtus wrote: post #11

Earlier quoted context omitted.

Don't you think that with the tools we have now it's easier to control the quality of code produced (Clang memory sanitizers and so on)? I feel more at ease to ship C code today after instrumenting it than a few years ago...

Not really, as it is proven almost on daily basis. https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=memory+corr...

How do you know that developers working on those used tools such as the Clang Memory Sanitizer?

Re: C considered dangerous

#63

Post by pjmlp »

FraKtus wrote: post #62
pjmlp wrote: post #26

Earlier quoted context omitted.

Not really, as it is proven almost on daily basis. https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=memory+corr...

How do you know that developers working on those used tools such as the Clang Memory Sanitizer?

Because many on that list are well known FOSS projects that supposedly have such processes in place, including manual review before accepting patches into mainline, like the Linux kernel being discussed here.

Re: C considered dangerous

#64

Post by vardump »

notacoward wrote: post #61
vardump wrote: post #18

Earlier quoted context omitted.

I'm absolutely sure same skill level programmer will create less defects in Python, Erlang and Lua than in C. You really have to try to overwrite memory in those languages. Of course you can shoot yourself into foot with stuff like metatables in Lua and Python metaclasses and whatnot. Then again you should see some C macro messes around... Anyways I don't like when people defend C with that age old argument it requir…

> I'm absolutely sure same skill level programmer will create less defects in Python, Erlang and Lua than in C. Fewer defects, or just different (arguably less severe) defects? It's great that you're sure, but evidence would be even better.

Ok, that's a fair point. I don't have the evidence for that.

Scripting languages do have their pitfalls. Lua and python can have type mismatches and even typos causing misbehavior, things that usually aren't issues with C.

However, you do need significantly less code than in C.

Re: C considered dangerous

#65

Post by rurban »

rwmj wrote: post #6

> He asked: why is there no argument to memcpy() to specify the maximum destination length? I'm confused by this. The third argument provides the destination length, so what good would a "maximum destination length" do? I guess he must mean that because the length is often computed, you'd need a fourth argument to ensure the length isn't greater than some sane upper bound. But you can easily fix that using an if stat…

Just use memcpy_s. This has the destbuf size argument. It's even in C11, but you need the safeclib or MSVC, as no libc cares about the safety annex.

Re: C considered dangerous

#66

Post by rurban »

unwind wrote: post #45
willtim wrote: post #24

Earlier quoted context omitted.

The only support C is giving you for this is that it has sized unboxed types (and raw pointer access). Even then, you'd have to trust the compiler and take measurements to be sure.

That's not true, since C11 we have: #include void *aligned_alloc(size_t alignment, size_t size); which works like malloc() but lets you specify the required alignment.

Only for sizes <4KB
Post reply on HN