Live data from Hacker News

Legitimate Use of Variable Length Arrays

nullprogram.com

21–26 of 26 posts

Re: Legitimate Use of Variable Length Arrays

#21
post #12

Earlier quoted context omitted.

Um, no? That COPY_MAX would still need a different value between small MCU and full-blown PC. Not to mention that using stack allocation on low-memory device is extremely dangerous... at least with malloc you get a nice diagnostic, while alloca will just do random program damage.

It does not do random damage, you get a segmentation fault in most systems. In really small embedded you should not be allocating anything meaningful in the stack anyway.

In small embedded things are either statically allocated or allocated on the stack. There is no heap.

Re: Legitimate Use of Variable Length Arrays

#22

Earlier quoted context omitted.

> In support of flohofwoe's point: good implementations of malloc will, on the common path, just bump a pointer without synchronization. How does this work when the heap address space becomes fragmented, with randomly distributed available space and objects that are still live? You can't just bump when the next piece of memory may still be in use, and when you're not able to move memory.

That's the uncommon path.

Yes, exactly. And! It exists in garbage collectors, too.

Re: Legitimate Use of Variable Length Arrays

#23
post #11

Earlier quoted context omitted.

They're trying to allocate an n·n element array. If int and size_t are 32b (typical 32-bit architectures), and n == INT_MAX, then n·n·sizeof(float) can't be represented by a size_t. (Used · for multiplication, because HN turns stars into emphasis.)

That may be true but an array of n x n chars where n is 2^32 won't fit (well obviously) in RAM and size_t should be at least 64 bit to match (2^32 x 2^32 = 2^64). Regardless, even without these unobtainium big machines, the cardinality of the largest array for a platform (by any number of dimensions) must be representable in size_t. A too large of an array would not fit in RAM and you should get a compile/link/out of…

> A too large of an array would not fit in RAM and you should get a compile/link/out of memory error.

Except we're talking about variable sized arrays, where the wanted size is not known until runtime (e.g. from user input). We can't check this at compile time.

This also isn't the same problem as an out of memory error; we need to check that nn didn't overflow the size of size_t, as well as that the memory allocation is successful. Something like:

    int n = /* run-time value */
    size_t sz = (size_t)n;
    // Check n fits in size_t.
    if ((int)sz != n) 
    sz *= sz * sizeof(float);
    // Check against overflow.
    if (((sz / (size_t)n) / sizeof(float)) != (size_t)n) 
    float *matrix = malloc(sz);
    // Check allocation succeeded.
    if (matrix == NULL) 

Re: Legitimate Use of Variable Length Arrays

#25
post #22

Earlier quoted context omitted.

Yes, exactly. And! It exists in garbage collectors, too.

Why would you ever encounter a fragmented Eden in a garbage collector?

I wasn't thinking of that case in particular, but that there are other instance in a garbage collector where you will not just be able to bump a pointer: you need to request more memory from the OS, or you need to start a collection phase before satisfying a memory request.

Re: Legitimate Use of Variable Length Arrays

#26
post #23

Earlier quoted context omitted.

That may be true but an array of n x n chars where n is 2^32 won't fit (well obviously) in RAM and size_t should be at least 64 bit to match (2^32 x 2^32 = 2^64). Regardless, even without these unobtainium big machines, the cardinality of the largest array for a platform (by any number of dimensions) must be representable in size_t. A too large of an array would not fit in RAM and you should get a compile/link/out of…

> A too large of an array would not fit in RAM and you should get a compile/link/out of memory error. Except we're talking about variable sized arrays, where the wanted size is not known until runtime (e.g. from user input). We can't check this at compile time. This also isn't the same problem as an out of memory error; we need to check that n n didn't overflow the size of size_t, as well as that the memory allocatio…

One is still confined by the limitations of the target machine. Ignoring them is at one's own peril.
Post reply on HN