Live data from Hacker News

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

lemon.rip

111–120 of 257 posts

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

#111
post #11

They mention that while loops are limited because C doesn't have tail recursion. However, in my experience gcc and clang are pretty decent at tail recursion. It happens via the -foptimize-sibling-calls setting, which is enabled by default on -O2 or higher. The caveat is that the standard doesn't guarantee these optimizations. But there are some non-standard __attribute__ declarations that can help with that.

Well, I meant that loops are limited within the normal constraints of the C standard, which doesn't offer tail call elimination, but indeed as you point out it is easy to work around it in practice using clang or gcc optimization passes.

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

#112
post #6

Thanks to them being yet another attack vector and funny stuff like on this post, got demoted to optional on C11. Additionally Google spent several years paying to clean up the Linux kernel from all VLA occurrences. https://www.phoronix.com/news/Linux-Kills-The-VLA

>Thanks to them being yet another attack vector and funny stuff like on this post, got demoted to optional on C11. Sadly, the C committee doesn't really understand what was wrong with VLAs and a sizable group of its members wants to make them mandatory again: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2921.pdf ("Does WG14 want to make VLAs fully mandatory in C23")

the only result of banning VLAs is to force everyone to use alloca, which is even less safe.

exhibit A: https://lists.freedesktop.org/archives/mesa-commit/2020-Dece...

exhibit B: https://github.com/neovim/neovim/issues/5229

exhibit C: https://github.com/sailfishos-mirror/llvm-project/commit/6be...

etc etc

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

#113
post #3

Similar to making all your computations in the expressions for default arguments in python (and/or C++) and leaving the function bodies empty. Fancy, but not that mindboggling. What may surprise people is how and when these expressions are evaluated since they differ between languages.

It might not be mind-boggling , but it is highly unusual to people who "think in C". This is not C! This kind of stuff is why purists stick to C89. I'm uneasy about variable-length arrays at the best of times. It hadn't even occurred to me that you might have a variable-length array as a function argument.

> purists stick to C89

But the true Scotsman… uh, purist sticks to the K&R C as C89 has already lost some of the original elegance and simplicity. (Never mind that it’s a challenge since the general community has moved on.)

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

#114

Earlier quoted context omitted.

>Thanks to them being yet another attack vector and funny stuff like on this post, got demoted to optional on C11. Sadly, the C committee doesn't really understand what was wrong with VLAs and a sizable group of its members wants to make them mandatory again: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2921.pdf ("Does WG14 want to make VLAs fully mandatory in C23")

the only result of banning VLAs is to force everyone to use alloca, which is even less safe. exhibit A: https://lists.freedesktop.org/archives/mesa-commit/2020-Dece... exhibit B: https://github.com/neovim/neovim/issues/5229 exhibit C: https://github.com/sailfishos-mirror/llvm-project/commit/6be... etc etc

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

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

#115
post #64

> Side note: even though we can't return, main is the exception to the rule that reaching the closing } of a function returning non-void is verboten, Isn't it legal to fall of the end of the end of a non-void function, only just defined as UB to use the return value?

Correct.

> If the } that terminates a function is reached, and the value of the function call is used by the caller, the behavior is undefined.

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

#116
post #93
post #61

Earlier quoted context omitted.

Yes it does, C is defined in term of implementation defined, but finite sized pointers and integers, so the computational model of C is a finite state machine. But the size of the state space is so friggin' HUGE that that argument is completely irrelevant for all practical purposes.

Is this true? C is defined in terms of the operations that can be performed on objects in memory, which includes the concept of memory addresses and address manipulation; but I'm not aware of anything that would require that objects that do not have their address taken have unique addresses, or addresses at all. This is the same use of the as-if principle that allows so many local variables to live their entire life…

The C standard specifies that there is a constant UINTPTR_MAX.

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

#117
post #107
post #96

Earlier quoted context omitted.

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

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.

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

#118

Earlier quoted context omitted.

the only result of banning VLAs is to force everyone to use alloca, which is even less safe. exhibit A: https://lists.freedesktop.org/archives/mesa-commit/2020-Dece... exhibit B: https://github.com/neovim/neovim/issues/5229 exhibit C: https://github.com/sailfishos-mirror/llvm-project/commit/6be... etc etc

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 (Blacklist)

oh noes :((

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

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

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.

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

#120
post #93

Earlier quoted context omitted.

Is this true? C is defined in terms of the operations that can be performed on objects in memory, which includes the concept of memory addresses and address manipulation; but I'm not aware of anything that would require that objects that do not have their address taken have unique addresses, or addresses at all. This is the same use of the as-if principle that allows so many local variables to live their entire life…

The C standard specifies that there is a constant UINTPTR_MAX.

Yes. But, as I mention in the proposed implementation, this limits the number of unique addresses in an implementation. Values that do not need addresses do not consume this limited resource. There would be a limit on the number of items on the stack that can have their address taken, but I can't see why this would limit the number of items on the stack.

In e.g. the fizzbuzz implementation mentioned in another comment [1], even without tail call optimization the stack growth implied by the recursive call does not require the number of /addressed/ items on the stack to grow. (Thinking about it, I believe this is an equivalent statement to "the tail call optimization is valid.")

[1] https://old.reddit.com/r/C_Programming/comments/qqazh8/fizzb...

Post reply on HN