[PATCH] dlls/windows.globalization: don't allocate a partial structure

[Henri Verbeet]

On Wed, 23 Mar 2022 at 22:55, Chris Robinson <chris.kcat at gmail.com> wrote:
> On Wednesday, March 23, 2022 12:32:52 PM PDT Alexandre Julliard wrote:
> > An empty size is probably OK to use at this point. It's not clear how
> > much benefit it brings though, because obviously 1-size arrays in public
> > structures can't be changed.
>
> And I'm not sure it would change anything regarding this patch and ensuring
> the object is properly allocated. A flexible array member isn't guaranteed to
> be at the very end of the struct, it can overlap with some padding:
>
> struct Foo {
>     int a;
>     char b;
>     char c[];
> };
>
> On most systems, sizeof(struct Foo) will be 8 bytes, but 'c' would immediately
> follow 'b' causing offsetof(struct Foo, c[0]) to be 5. So if you use
> offsetof(struct Foo, c[count]) for the allocation size, anything less than
> c[3] would be under-allocating and create potential implicit overruns just
> like before. so you still need to do something like
>
> max(sizeof(struct Foo), offsetof(struct Foo, c[count])
>
> to ensure a proper minimum allocation size.
>
On some level, sure. It's perhaps also worth pointing out that memory
allocators tend to have a certain allocation granularity. E.g., asking
HeapAlloc() for 5 bytes wouldn't actually get you a 5 byte allocation;
you'd get at least 8.