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

Getting Past C

blog.ntpsec.org

Post reply on HN
Print view View original

261–270 of 504 posts

Re: Getting Past C

#261

Post by caf »

dbaupp wrote: post #236
AReallyGoodName wrote: post #226

Earlier quoted context omitted.

Arrays and pointers in C already have that int. That's why sizeof() works. The issue is an extra if statement on every single array and pointer access.

They don't, sizeof is a compile-time constant. On a pointer, sizeof() just reports the size of the pointer itself (i.e. 4 or 8 bytes on most modern platforms), not the size of the data to which it points (and sizeof(*pointer) reports the size of the type to which pointer points, it doesn't know anything about how many values of that type are stored). For an array, the length is known statically (i.e. it's in the type…

sizeof isn't always a compile-time constant: if it's applied to variably-modified type, it's not (obviously).

Re: Getting Past C

#262

Post by staticassertion »

Manishearth wrote: post #232
Animats wrote: post #202

Earlier quoted context omitted.

There's a lot more unsafe code in Rust crates than there should be. That's a fixable problem. Some stuff from the early days predates the optimizer getting smart enough that unsafe code isn't needed. I wrote on this a few days ago in a Rust topic.

While I now mostly agree with you that there is more unsafe code than there should be, I still maintain that the frequency of unsafe in a deptree is usually still small enough to be practically auditable, ignoring FFI. It could/should be much less, but it's not too bad. I've done such audits a few times and it's not been too hard and taken very little time. Auditing FFI is a whole other challenge, however :(

Hmmmm. Note to self - actually try to audit a reasonably sized project's unsafe code to see how reasonable it is.

Re: Getting Past C

#263

Post by MichaelBurge »

scott_karana wrote: post #249
MaulingMonkey wrote: post #171

Earlier quoted context omitted.

> Can anybody make a strong case to me as to why are buffer overflows considered an issue in C when it takes like 10 minutes to write and test an array implementation that prevents that from ever happening? The CVE database. Just because you 'can' write such an array implementation doesn't mean you will, doesn't mean your third party libs will, doesn't mean any of your legacy code uses it, and certainly doesn't mean…

Hate to tell you, but JavaScript implementations virtually all rely on C or C++ as well. And it's not limited to the VM itself: check out npm "native extensions" like `json`. Not to mention glibc, or the OSes themselves. By your definition, nothing is safe. And you're right ;)

That's the old "formal proofs are useless because the proof checker might have a bug" argument. It's not very persuasive.

Re: Getting Past C

#264

Post by ChemicalWarfare »

dreta wrote: post #27

Can anybody make a strong case to me as to why are buffer overflows considered an issue in C when it takes like 10 minutes to write and test an array implementation that prevents that from ever happening? I do agree that C has issues (though in my opinion neighter Rust nor Go address almost any of them) i just don't understand why are buffer overflows such a huge problem in C when the same thing is going to come up w…

technically you probably could limit yourself to using a "safe" subset of C - basically no pointer arithmetic, no strcopy() etc - but that would defeat the purpose of using C in a first place.

Re: Getting Past C

#265

Post by jstewartmobile »

rafinha wrote: post #251

I didn't understand why rust and go are natural alternatives to C. Wouldn't C++ be a more natural option? (Despite the fact that both go and rust are developed by third party companies)

I did a lot of C++ years ago, so maybe things have changed since then, but I think Rust and Go addressed a lot of the design flubs of C++.

My experiences getting things to compile across gcc and visual c++, dealing with strings (especially Microsoft's WCHAR), reliable integer sizes (pre stdint.h), and debugging templates were not things I would wish on anyone.

Re-doing some of my side projects in Go and Rust was a lot more enjoyable. I could focus on what I was doing instead of trying to work around deficiencies in the language and its libraries.

Re: Getting Past C

#266

Post by Veedrac »

temac wrote: post #199
loup-vaillant wrote: post #115

Earlier quoted context omitted.

With C++, the default is zero overhead, not safety.

If people start to consider bound checking branches as overhead (which, in some extremely rare limited cases, they are in the right to do so), they should as well understand what happen with e.g. some largely used calling convention such as the one of Windows. Even in optimised builds, a unique_ptr for example can have an overhead compared to a raw pointer, IIRC because it forces going through the stack. If I remembe…

If a call is statically dispatched, calling convention doesn't matter because static dispatch gets inlined away in hot functions. If a call is dynamically dispatched, you have much bigger things to worry about. Bounds checking is a much bigger problem for hot code.

Re: Getting Past C

#267

Post by nullc »

bvinc wrote: post #144
dhsjxhx wrote: post #113

Rather than looking for a new language, why not ban programs from writing to executable memory?

I'm not an expert in this field, but it's my understanding that this is often the case for C programs executing nowadays. The AMD64 architecture even has the NX bit. There are some other ways that this can be enabled too. But surprisingly, this doesn't solve all code execution security problems from buffer overflows. Sometimes exploiters can find non-executable memory to change that allows them to change the program…

> Sometimes exploiters can find non-executable memory to change that allows them to change the program behavior to do what they want, such as changing the command string that gets passed to a normal execve call later in the program.

Changing function pointers or the return value on the stack are the normal things to do. In particular if you corrupt the stack you can simply return into system() with whatever arguments you want.

Re: Getting Past C

#268

Post by caf »

_sh wrote: post #89
lacampbell wrote: post #63

Earlier quoted context omitted.

Would you care to provide a short rust implementation of reading an arbitrary length string from standard input? I have rust installed. I would be curious to benchmark it and see if is indeed faster than the same thing in C, using a user-defined bounds checked array.

It's not so much a question of benchmarks, it's that one of the standard C tools for reading an arbitrary string from standard input is gets(). And if you reach for that from the standard toolbox, you've failed before you've started.

gets() isn't part of the C standard anymore (it was entirely removed in C11, and prior to that was marked "obsolescent and deprecated" 18 years ago in C99).

Re: Getting Past C

#269

Post by rafinha »

jimbokun wrote: post #255
rafinha wrote: post #251

I didn't understand why rust and go are natural alternatives to C. Wouldn't C++ be a more natural option? (Despite the fact that both go and rust are developed by third party companies)

"out of C into a language with no buffer overruns, and in general much stronger security and correctness guarantees." Doesn't sound like C++.

I still don't get it. Can't it be done in c++ via appropriate data structures? I mean, it's not like Go is magic, at the end I suppose Go would be doing just that. As far as I know the main reason people opt for Go over C++ are the compiling times...

Re: Getting Past C

#270

Post by steveklabnik »

aduffy wrote: post #257
steveklabnik wrote: post #237

Earlier quoted context omitted.

It is by definition a "zero-cost abstraction." Let's ask Stroustrup, who coined the term: > C++ implementations obey the zero-overhead principle: What you don’t use, you don’t pay for. And further: What you do use, you couldn’t hand code any better. Two points: What you don't use, you don't pay for: if you don't use array indexing, you won't get a bounds check. In addition, you can call an access method without a bou…

This is actually a very helpful comment. I used to think "zero-cost" meant "at compile-time", as in `newtype` in Haskell, etc. I'm guessing that's what the parent commenter thought as well, and I'd guess is what most people think when they hear the phrase.

Thanks! It can definitely be a bit unintuitive at first. After all, everything has _some_ cost...
Post reply on HN