C99 doesn't need function bodies, or 'VLAs are Turing complete' • Hacker News Board

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

#251

Post by tialaramex » Sat, Aug 06, 2022, 12:58 AM UTC

legalcorrection wrote: post #235

tialaramex wrote: post #227

Earlier quoted context omitted.

> A lot of UB in the C standard is perfectly defined and consistent across MSVC, GCC, Clang, and ICC. Do you have examples of this "a lot of UB in the C standard" which is in fact guaranteed to be "perfectly defined and consistent" across all the platforms you listed ? You may need to link the guarantees you're relying on.

Okay so take the two most complained about UBs, improper aliasing and signed integer overflow. Every compiler I’ve ever used lets you turn both into defined behavior.

These things aren't the default, the compiler may "let you" but it doesn't do it until you already know you've got a problem and you explicitly tell it you don't want standard behaviour. However lets ignore that for a moment:

My GCC offers to turn signed integer overflow into either an abort or wrapping, either of which is defined behaviour, but how do I get MSVC to do precisely the same thing?

Likewise for aliasing rules. GCC has a switch to have the optimiser not assume the language's aliasing rules are actually obeyed, but what switch in MSVC does exactly the same thing?

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

#252

Post by saagarjha » Sat, Aug 06, 2022, 2:06 AM UTC

rhexs wrote: post #250

saagarjha wrote: post #248

Earlier quoted context omitted.

If your architecture does not support this then you’re at risk whenever you make a function call.

Backpedal harder!

I’m not backpedaling. If your environment has guard pages and does probing then it protects equally well against VLAs and function calls overflowing the stack. If it has neither then both are liable to overwrite other memory. Obviously I would prefer that you have the protections, or some sort of equivalent, but they have nothing to do with VLAs.

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

#253

Post by saagarjha » Sat, Aug 06, 2022, 2:08 AM UTC

throw827474737 wrote: post #202

saagarjha wrote: post #175

Earlier quoted context omitted.

Definitely not.

For the can be, or performance, or maintenance perspective?? With example please ..

You’ll find it difficult to beat a construct that has dedicated language support. Trying to fake function calls without actually making function calls is difficult and going to have poor ergonomics.

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

#254

Post by Someone » Sat, Aug 06, 2022, 5:49 AM UTC

bjourne wrote: post #245

Someone wrote: post #210

Earlier quoted context omitted.

An attacker could trigger a large VLA allocation that jumps over the guard page, and a write to that allocation. That write would start _below_ the guard page, so damage would be done before the page fault occurs (ideally, that write wouldn’t touch the guard page and there wouldn’t be a page fault but that typically is harder to do; the VLA memory allocation typically is done to be fully used) Triggering use of the i…

VLAs give the attacker an extra attack vector. The size of the VLA is runtime-determined and potentially controlled by user input. Thus, the only safe way to handle VLAs is to check that there is enough stack space for every VLA allocation. Which may be prohibitively expensive and even impossible on some embedded platforms. Stack overflows may happen for other reasons too, but letting programmers put dynamic allocati…

I don’t think “may be prohibitively expensive and even impossible on some embedded platforms” is a strong argument for not including it in C. There are many other features in C for which that holds, such as recursion, dynamic memory allocation, or even floating point.

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

#255

Post by legalcorrection » Sat, Aug 06, 2022, 6:11 AM UTC

tialaramex wrote: post #251

legalcorrection wrote: post #235

Earlier quoted context omitted.

Okay so take the two most complained about UBs, improper aliasing and signed integer overflow. Every compiler I’ve ever used lets you turn both into defined behavior.

These things aren't the default, the compiler may "let you" but it doesn't do it until you already know you've got a problem and you explicitly tell it you don't want standard behaviour. However lets ignore that for a moment: My GCC offers to turn signed integer overflow into either an abort or wrapping, either of which is defined behaviour, but how do I get MSVC to do precisely the same thing? Likewise for aliasing…

MSVC doesn’t enforce strict aliasing to begin with. And passing /d2UndefIntOverflow makes signed integer overflow well-defined. Even if you don’t pass it, MSVC is very conservative in exploiting that UB, precisely to avoid breaking code that was valid before they started doing this optimization (2015 or so).

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

#256

Post by naasking » Sat, Aug 06, 2022, 8:27 AM UTC

samatman wrote: post #106

pjmlp wrote: post #98

Earlier quoted context omitted.

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.

The difference between the largest sushi knives and a katana is more about who wields them than the blade involved.

When you really need a samurai, nothing less will do. Arguably most of us need sushi chefs these days.

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

#257

Post by ordu » Sat, Aug 06, 2022, 5:14 PM UTC

dataflow wrote: post #240

kllrnohj wrote: post #231

Earlier quoted context omitted.

We're talking about function inputs, not system inputs.

Real-time is a property of the whole system though (?) not individual functions. But even if you want to reframe it to be about functions, small input is neither necessary nor sufficient for it being "real time". Like your function might receive an arbitrarily large n-element array a[] and just return a[a[n-1]], and it would be constant time. Again, the size is the simply not the correct property to look at.

> Real-time is a property of the whole system though (?) not individual functions.

As I see it, it leads to a contradiction. `cat` have unbounded time of execution. It depends on a size of input. It means that `cat` cannot be realtime. But this logic leads us to a conclusion, that any OS kernel cannot be realtime, because it works for an unbounded time.

It is a non sense. Realtime is about latency: how much it takes time to react to an input. `cat` may be realtime or may be not, it depends on how we define "input". We need to define it in a way that it is bounded. I mean 4Kb chunks of bytes for example.

> Like your function might receive an arbitrarily large n-element array a[] and just return a[a[n-1]], and it would be constant time.

No. Receiving n-element array is an O(n) operation. It needs to be copied to memory. We can of course pick one function that just get a pointer to an array, but if real-time is a property of the whole system, then this system needs to copy the array from the outside world into memory. And it is an O(n) operation. So for any latency requirement exists such N so when n>N this requirement would not be met. So unbounded array as an input is incompatible with a real-time.