Allow truncation to work within VFileFromMemory

[CasualPokePlayer]

Truncation here is limited to buffer size (allowing for shrinking but not growing the VFile size)

[endrift]

I'm curious what this is useful for.

[endrift]

Expanding the size to match the buffer size after shrinking should not be allowed because the expectation of an expanded buffer is that the remainder is zeroed, which will not be the case for const mem. You'd also need a separate implementation for non-const mem.

[CasualPokePlayer]

Zeroed as in there would just be a memset within the existing buffer within the "expanded" space?

[CasualPokePlayer]

I assume f50a383 should cover this. For VFileFromConstMemory, I've backed out those changes entirely (I suppose anyways under strict ftruncate semantics you can't truncate at all when the file is read-only).

Not sure entirely if clamping the size done is correct here. Under strict ftruncate semantics, expanding past the maximum file size is just an error (EFBIG or EINVAL or EPERM) rather than a clamp.

[CasualPokePlayer]

I'm curious what this is useful for.

The intent of this is mainly for VFileFromMemory. I'm trying to work on removing internal header usage within GSE, and one of the usages is just trying to look into savedata size. With the current code, truncation would do nothing here, so the savedata vf would just be the maximum savedata size, so the only way to know the actual savedata size is internal functions. By having truncation do something, the savedata vf can initially be set to 0, then later mGBA functions can grow the buffer, at least until it hits the maximum size.

Although in hindsight, this also doesn't really work well unless write is also able to "expand" the size until the buffer size (for RTC writes), so that'd need to be updated too.

[endrift]

I think this wound up in the wrong PR, or at least the wrong commit. Could you fixup the history at least?

[CasualPokePlayer]

It's have VFileFromMemory write "expand" size until the buffer size. Is this better as separate commits or separate PRs? (or squashing all the history into one commit?)

[endrift]

Same PR is fine, but one of the commits is basically "back out half of the last commit, and also this", so instead just splitting out the first half and then doing a fixup in to the previous commit would be preferable.