On Wed, 2 Apr 2025 13:09:46 GMT, Nikita Gubarkov <ngubar...@openjdk.org> wrote:
>> I see a way to deal with this problem though - we don't have to deal with
>> the ambiguity, but just allocate enough memory to be on the safe side no
>> matter the interpretation of the layout - with the example I provided
>> earlier `bandOffsets = {1, 2, 3}` and `pixelStride=4`, just allocate 1 extra
>> byte at the end to prevent out-of-bounds access in any case.
>
>> Or maybe we should modify the code that relies on the current size?
>
> I have mixed feelings about that. It sounds logical "mathematically", so to
> speak, but in practice there are assumptions other code often relies on,
> which are so natural, that breaking them would be like shooting ourselves in
> the foot.
>
> This follows the same logic as C struct layout: unused padding is considered
> an integral part of the struct layout and its size - we can always `memcpy` a
> struct with its `sizeof` without calculating the position of the last byte
> which actually holds meaningful data.
> Following this:
> 1. `pixelStride` equals to the size of the pixel - it must always be resident
> in memory together with any padding it includes
> 2. `scanlineStride` equals to the size of the scanline - it must always be
> resident in memory together with any padding it includes
> 3. Derived from the latter: `dataSize >= height * scanlineStride` - yes, we
> could have unused space in the end of the scanline, but it is often assumed
> that we can copy the whole image with just `height * scanlineStride` without
> worrying about the last scanline ruining our day.
>
> I find this logic very natural and convenient, that's why I think we need to
> fix the size calculation and not its usage.
Please see the related PR: https://github.com/openjdk/jdk/pull/24378
It tries to solve the similar problem of calculating pixel-aligned starting
offset from given band offsets, so this discussion also applies there.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24111#discussion_r2024833503
