4 ms·
For the people who actually care about using C, there can be no unified concept of "array". Any single "the system" will just plain and simply be unusable in a
by dzaima 2y ago
For the people who actually care about using C, there can be no unified concept of "array". Any single "the system" will just plain and simply be unusable in a good majority of situations.
Some people will want to store the size in a type smaller than size_t (and potentially place it not adjacent to the data pointer for better packing in a struct; or perhaps even bit-pack it). Some will want to place the size relative to the data instead of the pointer (esp. flexible array members). Some will want to store half (or a third, etc) of the element count, the array being used as multiple back-to-back arrays. Then you'll have questions on pointers in the middle of an array, indexable by positive and negative indices. Never mind the pretty significantly increased register shuffling of having to pass the size across functions.
For projects that are fine with doing things in the single way forced upon you and don't care about how things are done as long as it's safe, C is already rather clearly not the language to choose.
C++ as-is can already pretty trivially allow adding bounds-checked array types, and compilers can even be configured to warn on all pointer indexing (https://godbolt.org/z/W8sqGW5sh https://godbolt.org/z/W8sqGW5sh), achieving the entirety of your proposal while not locking people into a single data structure. (granted, some may not want to expand to C++ "just" for one or two features (me included), but here allowing customizable array data structures is basically the only sane option, and C would have to take a rather significant amount from C++ to allow for such itself)
- lisper 2y ago> Some people will want to store the size in a type smaller than size_t So? My point here is that this should be the compiler's responsibility, not the programmer's. Why could not a compiler bitpack the same way -- or even better than -- a programmer could?
- dzaima 2y agoThe compiler cannot change the length field's size if a reference to the array (or a struct where it's contained) is ever passed to an unknown function, as that function has to be able to read the length from memory based just on the spelled-out type. Not a problem when passing the array by value (i.e. two registers of the data pointer and length), but then any packing automatically does not apply anyway.
- lisper 2y agoI don't understand this. Why does it matter if you're calling an unknown function? Why would an unknown function be unable to get the length? All you would need to do is to change the behavior of SIZEOF to make it aware of dynamically allocated arrays.
- dzaima 2y agoI mean in the case of an array type that tracks its length at runtime. Take: typedef struct { uint32_t arr1_len, arr2_len; int* arr1; int* arr2; } Foo; That's, on a 64-bit system, a 24-byte structure. Were it written as a struct of two array fields, the compiler couldn't choose a layout as efficient while maintaining being able to get a pointer to each field. Never mind that the compiler would likely not be omniscient enough to be able to tell that the structure is never used with arrays exceeding 2^32 elements. Perhaps you mean to keep using regular pointers for non-trivial heap-stored things, but I'd imagine that makes up a pretty significant amount of cases with buffer overflow potential.
- actionfromafar 2y agoOr add another sizeof keyword.