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

121–130 of 257 posts

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

#121

Post by kllrnohj »

chjj wrote: post #96
rwmj wrote: post #82

Earlier quoted context omitted.

VLAs make it a lot easier to corrupt the stack by accident. Unless you're quite a careful coder, stuff like: f (size_t n) { char str[n]; leads to a possible exploit where the input is manipulated so n is large, causing a DoS attack (at best) or full exploit at worse. I'm not saying that banning VLAs solves every problem though. However the main reason we forbid VLAs in all our code is because thread stacks (particula…

You shouldn't be writing C if you're not a careful coder.

Hint, that means nobody should be writing C.

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

#123

Post by tedunangst »

jcelerier wrote: post #118
tedunangst wrote: post #114

Earlier quoted context omitted.

Nobody is forced to use alloca, which is not less safe, only equally disastrous. Just use malloc, already.

ah yes, why didn't I think of it, let me just try: #include #include __attribute__((annotate("realtime"))) void process_floats(std::span vec) { auto filter = (float*) malloc(sizeof(float) * vec.size()); /* fill filter with values */ for(int i = 0; i ) _Z14process_floatsSt4spanIfLm18446744073709551615EE ##The Deduction Chain: ##The Contradiction Reasons: - malloc : NonRealtime (Blacklist) - free : NonRealtime (Blackli…

Here's a nickel, kid.

The bullshit about oh my embedded systems doesn't have dynamic memory is bullshit. You either know how big your stack is and how many elements there are, and you make the array that big. Or you don't know and you're fucked.

You can't clever your way out of not knowing how big to make the array with magic stack fairy pretend dynamic memory. You can only fuck up. Is there room for 16 elements? The array is 16. Is there room for 32? It's 32.

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

#124

Post by jasonhansel »

rwmj wrote: post #82
planede wrote: post #38

Earlier quoted context omitted.

You can corrupt the stack without VLAs just fine. What else?

VLAs make it a lot easier to corrupt the stack by accident. Unless you're quite a careful coder, stuff like: f (size_t n) { char str[n]; leads to a possible exploit where the input is manipulated so n is large, causing a DoS attack (at best) or full exploit at worse. I'm not saying that banning VLAs solves every problem though. However the main reason we forbid VLAs in all our code is because thread stacks (particula…

Doesn't a similar DoS risk (from allowing users to allocate arbitrarily large amounts of memory) also apply to the heap? You shouldn't be giving arbitrary user-supplied ints to malloc either.

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

#125

Post by dataflow »

tedunangst wrote: post #123
jcelerier wrote: post #118

Earlier quoted context omitted.

ah yes, why didn't I think of it, let me just try: #include #include __attribute__((annotate("realtime"))) void process_floats(std::span vec) { auto filter = (float*) malloc(sizeof(float) * vec.size()); /* fill filter with values */ for(int i = 0; i ) _Z14process_floatsSt4spanIfLm18446744073709551615EE ##The Deduction Chain: ##The Contradiction Reasons: - malloc : NonRealtime (Blacklist) - free : NonRealtime (Blackli…

Here's a nickel, kid. The bullshit about oh my embedded systems doesn't have dynamic memory is bullshit. You either know how big your stack is and how many elements there are, and you make the array that big. Or you don't know and you're fucked. You can't clever your way out of not knowing how big to make the array with magic stack fairy pretend dynamic memory. You can only fuck up. Is there room for 16 elements? The…

I think the parent comment was about malloc not being real-time? Not about storage space.

Though I do wonder why there can't be a form of malloc that allocates in a stack like fashion in real time to satisfy the formal verifier?

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

#126

Post by pjmlp »

chjj wrote: post #117
pjmlp wrote: post #107

Earlier quoted context omitted.

Yeah, right. https://msrc-blog.microsoft.com/2019/07/16/a-proactive-appro... https://research.google/pubs/pub46800/ https://support.apple.com/guide/security/memory-safe-iboot-i... Maybe you could give an helping hand to Microsoft, Apple and Google, they are in need of carefull C coders.

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.

The goal should be to reduce the amount of sharp edges, not increase them even further.

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

#127

Post by lelanthran »

jasonhansel wrote: post #124
rwmj wrote: post #82

Earlier quoted context omitted.

VLAs make it a lot easier to corrupt the stack by accident. Unless you're quite a careful coder, stuff like: f (size_t n) { char str[n]; leads to a possible exploit where the input is manipulated so n is large, causing a DoS attack (at best) or full exploit at worse. I'm not saying that banning VLAs solves every problem though. However the main reason we forbid VLAs in all our code is because thread stacks (particula…

Doesn't a similar DoS risk (from allowing users to allocate arbitrarily large amounts of memory) also apply to the heap? You shouldn't be giving arbitrary user-supplied ints to malloc either.

> Doesn't a similar DoS risk (from allowing users to allocate arbitrarily large amounts of memory) also apply to the heap?

DoS Risk? No one cares too much about that - the problem with VLAs is stack smashing, which then allows aribtrary user-supplied code to be executed.

You cannot do that with malloc() and friends.

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

#128

Post by danuker »

wizofaus wrote: post #119
mjcohen wrote: post #105

Earlier quoted context omitted.

What the heck. It's "moot", not "mute".

I'm curious, are there accents in which those two words are homophones? Given the US tendency to pronounce new/due/tune as noo/doo/toon I can imagine some might say mute as moot but I can't find anything authoritative online.

They are not perfect homophones. There is a slight i (IPA j) in "mute".

https://en.wiktionary.org/wiki/mute

https://en.wiktionary.org/wiki/moot

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

#129

Post by lelanthran »

svnpenn wrote: post #9

This kind of insanity is exactly why I don't use stuff like C anymore. It's a landmark and incredible language, but it's chock full of potholes and foot-shotguns (footguns that blow off your entire leg). Even huge companies can't get it right, which makes sense. It started as a language basically without guardrails, and because of the extreme deference to the holy backward compatibility, it's more or less always goin…

> It's a landmark and incredible language, but it's chock full of potholes and foot-shotguns (footguns that blow off your entire leg).

There are very few footguns in C, compared to (say) C++ (or Python).

I can guarantee you that no employed C developer is putting IOCCC type code into shipping products. Pick any language you like, and turn up the code golfing to 11, and you'll be equally horrified.

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

#130

Post by lelanthran »

camel-cdr wrote: post #41

This is only tangential to the article: C isn't Turing complete without `fseek` (as far as I can tell). Turing completes requires you to be able to read/write from an infinite tape (essentially infinite memory). 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. From…

> 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 theory, there is no upper limit on size_t.

Post reply on HN