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

181–190 of 257 posts

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

#181

Post by [deleted] »

tremon wrote: post #147
marssaxman wrote: post #92

Earlier quoted context omitted.

It's not that the behavior was defined by the C standard, but that you could confidently predict what a given compiler would generate, for a given platform, so it was quite normal to write programs which made productive use of officially-undefined behavior when that was the behavior you wanted. (It may well have been defined by that particular compiler's documentation.) Nowadays, people are used to thinking entirely…

you could confidently predict what a given compiler would generate, for a given platform But then you're no longer writing Standard C. You're writing compiler-flavoured C, which is another source of footguns for projects that outlive the compiler (or version) they were originally written for. Which is fine, as you say, for embedded-style projects that only target one processor model and one compiler version. But I do…

[deleted]

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

#182

Post by camel-cdr »

GabrielTFS wrote: post #173
camel-cdr wrote: post #156

Earlier quoted context omitted.

I don't think infinitely large integer constant area construct that makes sense. As far as I'm aware, there isn't an instance of an infinitely large integer, even in mathematics, there are finite integers and there is the concept of infinity. (And size_t is defined as an unsigned integer type)

I'd argue you could use non-standard integers that are unable to be reached in a finite amount of steps but aren't infinity and are still "integers".

> unable to be reached in a finite amount of steps but aren't infinity

I don't see how such numbers can exit/be used/defined in any meaningful way. Do you have an example of such a number?

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

#183

Post by shawnz »

SavageBeast wrote: post #68
nneonneo wrote: post #36

Earlier quoted context omitted.

It’s not an array element :) The printf statement is part of the length expression, i.e. it’s setting the length of the array to the result of the printf call. So it is indeed a “value”. This isn’t much different from writing something like this in JS: var a = []; a[console.log("Hello"), 1] = 42; except that this indexes the array as opposed to setting its length.

I spent the past 10 minutes figuring out what to search for (C is very rusty here) regarding C arrays and initialization. Now that you point it out, it seems obvious. It certainly wasn't obvious when I read it though. This is some really obtuse use of a language here - hilariously so really. The code in the array is executed as a function that determines the array size and I see that now - thanks. If someone on my te…

The feature is called variable length arrays (VLAs)

See https://www.ibm.com/docs/en/i/7.4?topic=arrays-variable-leng...

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

#184

Post by Kamq »

kllrnohj wrote: post #158
asguy wrote: post #101

Earlier quoted context omitted.

> I haven't thought about C in years ... Im going to stick with my VM over here and call it a day. What's your VM written in?

Probably not C regardless. How many widely used VMs are in C? Python is about it, right?

Java's? Or at least it used to be.

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

#185

Post by cozzyd »

tedunangst wrote: post #65
google234123 wrote: post #56

What is the best alternative when I want to allocate some reasonably sized array on the stack and don’t want to always reserve the worst case size? alloca?

Reserve the maximum every time.

That has cache friendliness implications though, doesn't it? Seems better to just cap the size of the allocation and use a VLA.

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

#186

Post by bjourne »

Dylan16807 wrote: post #168
anyfoo wrote: post #166

Earlier quoted context omitted.

> I think the normal pattern is a stack probe every page or so when there's a sufficiently large allocation. What exactly are you doing there, in kernel code? > But that's not my point. If the compiler/runtime knows it will blow up if you have an allocation over 4KB or so, then it needs to do something to mitigate or reject allocations like that. Do what exactly? Just reject stack allocations that are larger than the…

> 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.

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

#187

Post by kllrnohj »

Kamq wrote: post #184
kllrnohj wrote: post #158

Earlier quoted context omitted.

Probably not C regardless. How many widely used VMs are in C? Python is about it, right?

Java's? Or at least it used to be.

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

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

#188

Post by asguy »

kllrnohj wrote: post #187
Kamq wrote: post #184

Earlier quoted context omitted.

Java's? Or at least it used to be.

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.

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

#189

Post by legalcorrection »

tialaramex wrote: post #171
mtlmtlmtlmtl wrote: post #152

Earlier quoted context omitted.

I think this is a common misunderstanding about UB. It's not that anything can happen, just that the standard doesn't specify what happens, meaning whatever happens is compiler/architecture/OS dependent. So you can't depend on UB in portable code. But something definite will happen, given the current state of the system. After all, if it didn't, these things wouldn't be exploitable either.

> But something definite will happen, given the current state of the system. This is only true in the very loose and more or less useless sense that the compiler is definitely going to emit some machine code. What does that machine code do in the UB case? It might be absolutely anything . One direction you could go here is you insist that surely the machine code has a defined meaning for all possible machine states,…

You are confusing the C standard and actual platforms/C implementations. A lot of things are UB in the standard but perfectly well defined on your platform. Standards don’t compile code, real compilers do. The standard doesn’t provide standard library implementations, the actual platform does.

Targeting the standard is nice, but if all of your target platforms guarantee certain behaviors, you might consider using those. A lot of UB in the C standard is perfectly defined and consistent across MSVC, GCC, Clang, and ICC.

Post reply on HN