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

C99 doesn't need function bodies, or 'VLAs are Turing complete'

lemon.rip

Post reply on HN
Print view View original

191–200 of 257 posts

Re: C99 doesn't need function bodies, or 'VLAs are Turing complete'

#191

Post by Dylan16807 »

bjourne wrote: post #186
Dylan16807 wrote: post #168

Earlier quoted context omitted.

> What exactly are you doing there, in kernel code? In kernel code? What you're doing is triggering the guard page over and over if the stack is pushing into new territory. > Do what exactly? Just reject stack allocations that are larger than the cluster of guard pages? And keep book of past allocations? A lot of that needs to happen at runtime, since the compiler doesn't know the size with VLAs. Just hit the guard p…

An attacker would first trigger a large VLA-allocation that puts the stack pointer within a few bytes of the guard page. Then they would just have the kernel put a return address or two on the stack and that would be enough to cause a page fault. The only way to guard against that would be to check that every CALL instruction has enough stack space which is infeasible.

But that's the entire point of the guard page, it causes a page fault. That's not corruption.

Denial of service by trying to allocate something too big for the stack is obvious. I'm asking about how corruption is supposed to happen on a reasonable platform.

Re: C99 doesn't need function bodies, or 'VLAs are Turing complete'

#192

Post by legalcorrection »

pjmlp wrote: post #39
ynfnehf wrote: post #31

Earlier quoted context omitted.

This usage of VLAs is once again mandatory for compilers to support, since C23. From Wikipedia: "Variably-modified types (but not VLAs which are automatic variables allocated on the stack) become a mandatory feature".

Oh well...

Tell me, what’s wrong with variably modified types specifically?

Re: C99 doesn't need function bodies, or 'VLAs are Turing complete'

#193

Post by legalcorrection »

asguy wrote: post #188
kllrnohj wrote: post #187

Earlier quoted context omitted.

Openjdk seems to be more c++ than c according to GitHub anyway. In particular the "interesting" stuff (so hotspot) looks to be all c++.

It started as C. It’s interesting to watch people post comments, as though C vs C++ makes the distinction in “safety” in a code base. The take away I’m getting is most have programmed in neither.

These people are just regurgitating HN memes and then flailing when someone prods a bit deeper. C is basically the Donald Trump of HN. All rational thought goes out the door at the mere mention. In fact, you’re socially rewarded for joining the idiot mob.

Re: C99 doesn't need function bodies, or 'VLAs are Turing complete'

#194

Post by [deleted] »

Banana699 wrote: post #148
asguy wrote: post #143

Earlier quoted context omitted.

Except for most of deno that's written in Unsafe C++. https://v8.dev/

A JS runtime is a lot more than the core engine, or else nodejs is just a thin wrapper over V8 as well, which is obviously absurd. So without a count of the source lines for each language's portion of the implementation (very rough but acceptable first approximation of how much is implemented in each), you can't claim C++ is doing most of the heavy lifting and be taken seriously. PS. the worst C++ code is still a hel…

[deleted]

Re: C99 doesn't need function bodies, or 'VLAs are Turing complete'

#195

Post by lelanthran »

camel-cdr wrote: post #134
lelanthran wrote: post #130

Earlier quoted context omitted.

> This isn't possible in C, because `sizeof` is a constant expression, thus limiting the size of any type, and importantly also pointer type, to a finite number, thus making the addressable memory finite. Who said it had to be finite in theory ? `size_t` is defined in terms of the implementation, not in terms of bit-widths. Sure, size_t is finite in practice, but then again, so are all other programming languages. In…

`size_t` is defined as > the unsigned integer type of the result of the sizeof operator ( https://port70.net/~nsz/c/c11/n1570.html#7.19p2 ) `sizeof` returns the following: > If the type of the operand is a variable length array type, the operand is evaluated; otherwise, the operand is not evaluated and the result is an integer constant. ( https://port70.net/~nsz/c/c11/n1570.html#6.5.3.4p2 ) So `sizeof(size_t)` must b…

> So `sizeof(size_t)` must be a concrete integer constant for any given C implementation, it can't change at runtime.

I didn't say it has to change at runtime, I said that there is no upper limit on it in theory, because the upper limit is specified in terms of the implementation, and a a theoretical implementation with no upper limit on memory means that there is no upper limit on size_t.

Besides, I also said:

> Sure, size_t is finite in practice, but then again, so are all other programming languages.

Using your definition of Turing complete (no upper limit on pointer, references or addresses), I cannot think of one popular language that would satisfy that definition. Can you?

Re: C99 doesn't need function bodies, or 'VLAs are Turing complete'

#196

Post by arinlen »

pjmlp wrote: post #98
arinlen wrote: post #71

Earlier quoted context omitted.

> What about not adding even more ways how we should avoid using C? That's a mute point for C's target audience because they already understand that they need to be mindful of what the language does.

That is like saying if sushi knifes are already sharp enough, there is no issue cutting fish with a samurai sword instead, except at least with the knife maybe the damage isn't as bad.

> That is like saying if sushi knifes are already sharp enough (...)

No, it's like saying that professional people understand the need to learn what their tools of the trade do beyond random stackoverflow search on how to print text to stdout.

It seems you have an irrational dislike of C. That's perfectly ok. No need to come up with excuses though.

Re: C99 doesn't need function bodies, or 'VLAs are Turing complete'

#197

Post by mananaysiempre »

legalcorrection wrote: post #192
pjmlp wrote: post #39

Earlier quoted context omitted.

Oh well...

Tell me, what’s wrong with variably modified types specifically?

Sizeof, which used to be one of the very few things you could blindly do to an arbitrary (potentially UB-provoking) expression, can now have side effects.

Re: C99 doesn't need function bodies, or 'VLAs are Turing complete'

#198

Post by astrange »

_0w8t wrote: post #131
chjj wrote: post #117

Earlier quoted context omitted.

I'm not sure if you intentionally missed my point. Everything in C requires careful usage. VLAs aren't special: they're just yet another feature which must be used carefully, if used at all. Personally, I don't use them, but I don't find "they're unsafe" to be a convincing reason for why they shouldn't be included in the already-unsafe language. Saying they're unnecessary might be a better reason.

VLAs are unsafe in the worst kind of way as it is not possible to query when it is safe to use them. alloca() at least in theory can return null stack overflow, but there is no such provision with VLA.

They're not unsafe (in the memory sense) as long as they check for overflow and reliably crash if there is one.

Re: C99 doesn't need function bodies, or 'VLAs are Turing complete'

#199

Post by astrange »

Banana699 wrote: post #148
asguy wrote: post #143

Earlier quoted context omitted.

Except for most of deno that's written in Unsafe C++. https://v8.dev/

A JS runtime is a lot more than the core engine, or else nodejs is just a thin wrapper over V8 as well, which is obviously absurd. So without a count of the source lines for each language's portion of the implementation (very rough but acceptable first approximation of how much is implemented in each), you can't claim C++ is doing most of the heavy lifting and be taken seriously. PS. the worst C++ code is still a hel…

> PS. the worst C++ code is still a hell of a lot more safe than the best C code.

What? For safe code you need to be able to audit it for logic errors, which you can't do if you can't understand what it does by reading it.

That's why especially fancy code is banned in projects like Linux.

Re: C99 doesn't need function bodies, or 'VLAs are Turing complete'

#200

Post by astrange »

hxtk wrote: post #46
tooltower wrote: post #24

Earlier quoted context omitted.

What old C do you mean? I can't think of any version where undefined had a defined meaning

Not defined as part of the standard, but before compilers got as smart about their optimizations, it was easier to have behavior that was technically undefined but could be reasoned about in practice. Now that compilers know cleverer optimizations, undefined behavior is often impossible to reason about because the compiler can change your logic into something else that is more optimal and is equivalent to your logic…

Modern compilers also come with UBSan. Either run it through that, or just always build with it enabled.
Post reply on HN