> Things are also legal in LLVM IR that are not legal in any of the languages it supports, for example, getelementptr can be used with negative indices, etc.

Not sure what you're talking about here; what's wrong with negative indices in C?

First, remember that getelementptr != array indices.

Second, remember that even in C, you can't actually dereference things outside of the bounds of an object, even if you can form addresses to it.

In any case, the point was more than something like

  struct foo C;

  char *foo = &C
  foo -= 7;
  char whee = *foo;

Is legal in llvm, but not in say, C++ (and in fact, in most languages it's not legal because it's not aligned properly)

"char" in C/C++ can't be misaligned.

I didn't say it can, i said "in fact, in most languages" (IE not C/C++). In C/C++, it's illegal for other reasons.

I Am Not A Language Lawyer, but there's no way that negative indices aren't UB in C.

  int a[100];
  int *p = &a[50];
  a[0] = 666;
  printf("%d\n", p[-50]);

Remember that x[y] in C just means *((x)+(y)). You can offset pointers with positive and negative offsets so long as the resulting pointer remains within the bounds of an object.

(EDIT: formatting so HN doesn't misinterpret code point U+2A.)

I actually use negative indices in real code[1].

If you implement a stack using an array and you track the top of stack by a pointer just past the last element, then you can index negatively into that pointer to access items on the stack:

    // Create an empty stack.
    int stack[100];
    int* top = &stack;

    // Push a couple of values.
    *top++ = 123;
    *top++ = 456;

    // Peek the values.
    printf("%d\n", top[-1]); // 456.
    printf("%d\n", top[-2]); // 123.

You could make the pointer arithmetic more explicit like this:

    printf("%d\n", *(top - 1)); // 456.

But I think that's needlessly verbose.

[1]: https://github.com/munificent/wren/blob/master/src/vm/wren_v...

For something like that, I would use the explicit pointer arithmetic. The array syntax implies (to me) "I am doing the normal thing with this normal array".

I'm aware that index notation in C is just sugar for pointer arithmetic, but I'm under the impression that the interpretation of "within the bounds of an object" is less liberal than that demonstrated in your code example. In particular it's not clear to me that a pointer derived from an offset into an existing allocation does not constitute a new object, with its own bounds. Maybe I'm just spoiled by languages with proper slices...

Your impression unfortunately turns out to not be the case. You can move pointers forward and backward within an array using pointer +/- integer arithmetic or (equivalently) the prefix and postfix ++/-- operators, and it's well-defined so long as you don't back up over the beginning of the array or go more than one element past the end.

See section 6.5.6, paragraph 8, of the ISO C standard, if you want the legalese. But this is pretty basic C that dates back to the beginning of the language.

This working is entirely necessary for C++-style handle-iterators to work. Rust's slice iterators are implemented in the exact same fashion precisely because C/C++ does this a lot and LLVM is trained to "get" it.