7 ms·

I'm sorry, but I think the article's version is actually closer to the truth. Regarding stack arrays, while the compiler certainly knows how large an array is

by yan 13y ago

I'm sorry, but I think the article's version is actually closer to the truth. Regarding stack arrays, while the compiler certainly knows how large an array is (of course it has to, you're using the length in the code it parses), it will almost certainly not write code or immediates that hold the size anywhere to the resultant binary. If you allocate three arrays, each of 12 doubles, a compiler can simply emit "sub esp, 288" and be done with it. It also won't stop you from referencing memory at an unreasonable offset from any of those arrays. (Compilers can warn you though.) Passing the array along with its size further goes to prove the original statement, not refute it. If you have to do something manually, it strongly implies that the language/runtime isn't doing it for you. Regarding arrays on the heap, the runtime even then does not require you to place a size anywhere. What likely happens is the right cell from a bucket of the closest size to the allocation you need is returned to you and marked in use. It will be as large as the size you're allocating, or larger. The only artifact of its original size is which span of memory it's located at. When you free() that allocation, that block simply gets marked as free, no size needed.

rayiner 13y ago
> What likely happens is the right cell from a bucket of the closest size to the allocation you need is returned to you and marked in use. It will be as large as the size you're allocating, or larger. The only artifact of its original size is which span of memory it's located at. Almost every segregated-fit allocator I've ever seen still stores the size of each cell in the bucket header, although of course you only need to store the size once for the whole bucket since each cell is the same size. Still, it's stored somewhere. Also, only some allocators are segregated fit. dlmalloc, for example, which is very widely used, uses boundary tags, storing the allocation size with the allocation itself.
- deleted 13y ago
  [deleted]
betterunix 13y ago
"What likely happens is the right cell from a bucket of the closest size to the allocation you need is returned to you and marked in use" ...implying that the size of the block is, in fact, available to the allocator. This might not be stored explicitly (it could be stored as a pair of pointers) but it is not unavailable. It is also necessarily available to the deallocator, which must in some way be aware of what it is marking as free. As I said, this might only be an approximation of the size of the array, though for bounds checking purposes it would usually be good enough (since nothing else should be allocated in the "excess" space that is marked as in-use). "Passing the array along with its size further goes to prove the original statement, not refute it. If you have to do something manually, it strongly implies that the language/runtime isn't doing it for you." Take a closer look at the original statement. He did not merely say that the size is unavailable to programmers, he said it is not available at all. That is not really true -- it is more that the compiler does not do anything useful with the information. To put it another way, a compiler could conceivably emit bounds-checking code but still not provide programmers with an explicit way to get the size of an array. The result would be the same: programmers would still be forced to pass array sizes around, to avoid a call to abort (or whatever behavior occurs when a bounds check failed).
- brigade 13y ago
  No it couldn't, because the compiler cannot make assumptions about the heap allocator beyond what the C spec says, which is basically just the function signatures. An allocator that never frees memory is entirely within the C spec and would need not know individual allocated sizes after allocation. Or, if a compiler decided to anyway, it would have to link a compiler-specific standard library because it's entirely implementation-dependant what and where bookkeeping information is stored. In turn, this means you couldn't safely link code compiled by different compilers. Bjarne might think that fine and dandy, but C never had that level of damage.

by yan 13y ago

rayiner 13y ago

> What likely happens is the right cell from a bucket of the closest size to the allocation you need is returned to you and marked in use. It will be as large as the size you're allocating, or larger. The only artifact of its original size is which span of memory it's located at. Almost every segregated-fit allocator I've ever seen still stores the size of each cell in the bucket header, although of course you only need to store the size once for the whole bucket since each cell is the same size. Still, it's stored somewhere. Also, only some allocators are segregated fit. dlmalloc, for example, which is very widely used, uses boundary tags, storing the allocation size with the allocation itself.

deleted 13y ago
[deleted]

betterunix 13y ago

"What likely happens is the right cell from a bucket of the closest size to the allocation you need is returned to you and marked in use" ...implying that the size of the block is, in fact, available to the allocator. This might not be stored explicitly (it could be stored as a pair of pointers) but it is not unavailable. It is also necessarily available to the deallocator, which must in some way be aware of what it is marking as free. As I said, this might only be an approximation of the size of the array, though for bounds checking purposes it would usually be good enough (since nothing else should be allocated in the "excess" space that is marked as in-use). "Passing the array along with its size further goes to prove the original statement, not refute it. If you have to do something manually, it strongly implies that the language/runtime isn't doing it for you." Take a closer look at the original statement. He did not merely say that the size is unavailable to programmers, he said it is not available at all. That is not really true -- it is more that the compiler does not do anything useful with the information. To put it another way, a compiler could conceivably emit bounds-checking code but still not provide programmers with an explicit way to get the size of an array. The result would be the same: programmers would still be forced to pass array sizes around, to avoid a call to abort (or whatever behavior occurs when a bounds check failed).

brigade 13y ago
No it couldn't, because the compiler cannot make assumptions about the heap allocator beyond what the C spec says, which is basically just the function signatures. An allocator that never frees memory is entirely within the C spec and would need not know individual allocated sizes after allocation. Or, if a compiler decided to anyway, it would have to link a compiler-specific standard library because it's entirely implementation-dependant what and where bookkeeping information is stored. In turn, this means you couldn't safely link code compiled by different compilers. Bjarne might think that fine and dandy, but C never had that level of damage.