What do you mean by C not having arrays?

It's syntactic sugar in the sense that arr[i] is just shorthand for *(arr+i)

There's no abstraction or 'concept' of arrays there. You are literally just telling the compiler to take a certain pointer and move i steps ahead.

Isn't that the definition of an array? Chunk of contiguous memory plus a notion of how to subdivide it into equal parts?

Yes, exactly. A chunk of memory. A chunk has an end.

But "arrays" in C aren't a chunk of memory, just the info where it starts and how large elements are.

The problem is that a frightening number of people don't bother to write the half-dozen obvious wrappers around this, and stdlib doesn't provide them either:

struct buf { uint8_t * base, size_t size };

> The problem is that a frightening number of people don't bother to write the half-dozen obvious wrappers around this

That's likely because having to pass it in and out of functions and libs that don't expect your special structure might cause it to have an invalid length, and then all your special wrappers can become a liability and not an advantage through either assuming your bufs are valid, or defensively checking more than is necessarily because they can't know whether it was altered or not.

> stdlib doesn't provide them either

Which is the real problem. That would make them a de facto standard, and a lot (but probably not all) of the problems would be mitigated by people accepting the performance trade offs needed to make them safe.

That doesn't solve the problem because you still have to set 'size' manually.

I assume they mean that C's support for "arrays" is essentially just C's support for pointer arithmetic plus a mapping of a[b] to *(a+b).

You can even swap it a[b] equivalent to b[a].

shouldn't it be:

* (a + b * sizeof(T))

where T is array elements' type?

That's implied in + on a pointer. uint32_t* + 1 actually adds 4.

Probably referring to the fact that they are simply pointers into contiguous memory.

C doesn't have "memory" in the standard. They're pointers into a contiguous object, but anything before a[-1] or after a[sizeof(a)-1] is undefined aka it actually doesn't exist.

`sizeof(a)` only gives the size of the array when the size is specified at compile time. Either you accept e.g. `int[16]` as a type, or you pass a pointer (for which `sizeof` just returns `sizeof(intptr_t)`)

That's not quite right. Arrays always have a knowable length, and sizeof will give a correct result for variable length arrays as well.

However, arrays that are passed as arguments to functions decay into raw pointers, at which point you lose information about its length.

> sizeof will give a correct result for variable length arrays as well.

In C99 with rather spotty support. And never with malloc and similar, which is how the vast majority of arrays are (and can be) created. And you can't return or store those dynamic arrays somewhere else without losing the size info, nor it can be declared static.

In other words, you're right but for very limited situations.

They are a pointer and an offset with no validation of bounds. But that's OK: C is little more than a high level assembly.

I hate the term "high level assembly" when applied to C since it's loaded against assembly (in the sense of C as its superset) which is obviously not true.

C is full of undefined behavior, assembly is not.

High level != Superset

Actually we often give up features and specialize with high level languages. That's why there are things easier to do in Ruby than in C++ and vice versa.

They are all (usually much more convenient) subsets of assembly.

What ? Assembly has undefined behavior, for example wrt unaligned access on some processors.