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

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")

What's your VM written in?

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.

What could possibly be surprising about reusing the exact same object on every function call, especially when you default to an empty list, set or dict. Getting an actual empty list is as easy as defaulting to None and explicitly checking for it, so there isn't even a reason to do it any differently. /s

Who the hell thought that this was sane behavior in a language with mostly mutable objects?

    #include <stdio.h>

    // "puts" makes "f" not constexpr.
    constexpr int f() { return puts("hello"); }

    // error: size of array 'argv' is not an integral constant-expression
    int main(int argc, char *argv[f()]) {}

Python default arguments are evaluated only once at function definition, not every function call. It's the source of one interesting WTF for anyone who assumes otherwise:

  def foo(a=[]):
    a.append(1)
    return a

  >>> foo()
  [1]
  >>> foo()
  [1, 1]
  >>> foo()
  [1, 1, 1]

Is this some portmanteau for “compile time optimization”?

[1] https://www.open-std.org/jtc1/sc22/wg14/www/wg14_document_lo...

The original purpose of VLAs is to let you stack-allocate an array with a length that is not known at compile time. In ANSI C you must heap-allocate such arrays, using malloc.

  void concat_strs(
    int str1_len,
    const char str1[str1_len],
    int str2_len,
    const char str2[str2_len],
    char out_str[str1_len + str2_len],
  );
  
  void manipulate_array(
    array_dim dim,
    int arr[dim.x][dim.y],
  );

Usually developers stick to known patterns and subsets. Sure, you can write "clever" code that's more aproppriate for IOCCC than as system-critical code, but that's the case with most programming languages.

There is such a thing as "bad code" and "good code". A lot of code linters can catch "code smells", and features can often be disabled at the compiler level.

On the other hand, not having to resort to inline assembler or writing 500x the amount of code in some cases is why we have such features. Complex features are useful in some (complex) cases, but are not to be overused.

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.

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

That is, could you build a compliant C implementation that implements a stack using an infinite memory (e.g. in a delay loop between the user and a mirror moving away through space), where each entry in the stack contains a convenient sized value (word, byte, whatever) and a tag? If the tag is clear, the value the contained directly in the infinite memory; if the tag is set, then the value is indirected into a fixed-sized memory. On taking the address of an item on the stack, if it is not already indirected, relocate it and indirect.

Of course the mechanism for doing stack unwinding on return needs to use relative operations ("drop five elements") and not chase frame pointers, but that seems trivial.

I admit I'm not super-familiar with all the details of the C specification, but it's not obvious to me that this would violate spec, and it would be Turing complete.

And yes neither is infinite, so every computer is just a DFA, and lseek changes nothing. But given the amount of memory that exists we approximate and say they are Turing machines since there is enough memory to do most what we need.

(Of course on a real machine the malloc() will fail at some point.)

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.

1. As https://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_260.htm helpfully points out, "If two objects have identical bit-pattern representations and their types are the same they may still compare as unequal", and "[implementations] may also treat pointers based on different origins as distinct even though they are bitwise identical". It can thus be argued that, with a rather strict definition of provenance (i.e. how pointer values may be constructed), one could construct an implementation where every byte of every pointer is tagged with additional unbounded data that lets the whole pointer be properly dereferenced (I say every byte so that you're able to convert the pointer to an integer and convert it back to the same valid pointer), and where, as allowed by DR 260, pointers that have identical observable bit-pattern representations might not compare equal if they point to different objects. Thus, that implementation could create an unbounded amount of pointers.

2. Spawning off another thread and using infinite recursion (C has no defined recursion depth limit, and if you want to argue about automatic variables needing addresses or whatever and that the as-if rule doesn't cover that, there's `register` which makes address-less variables) to have two pushdown automatas that can together work as a Turing Machine.

3. Using variadic arguments. With `va_copy`, one can iterate through variadic arguments multiple times, and thus `va_list` can be used to implement a mechanism equivalent to pointers without actual pointers (any sane implementation probably uses a pointer for `va_list` somewhere in it, but that's not a problem here) and thus make a pushdown automata with 2 stacks