qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 4/9] util/oslib-win32: Return NULL on qemu_try_memalign() wit


From: Peter Maydell
Subject: Re: [PATCH 4/9] util/oslib-win32: Return NULL on qemu_try_memalign() with zero size
Date: Thu, 3 Mar 2022 16:55:56 +0000

On Sun, 27 Feb 2022 at 18:36, Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> On 2/27/22 02:54, Peter Maydell wrote:
> >>> +    if (size) {
> >>> +        ptr = _aligned_malloc(size, alignment);
> >>> +    } else {
> >>> +        ptr = NULL;
> >>> +    }
> >>
> >> Oh, should we set errno to something here?
> >> Otherwise a random value will be used by qemu_memalign.
> >
> > Yeah, I guess so, though the errno to use isn't obvious. Maybe EINVAL?
> >
> > The alternative would be to try to audit all the callsites to
> > confirm they don't ever try to allocate 0 bytes and then have
> > the assert for both Windows and POSIX versions...
>
> Alternately, force size == 1, so that we always get a non-NULL value that can 
> be freed.
> That's a change on the POSIX side as well, of course.

Yes, I had a look at what actual malloc() implementations tend
to do, and the answer seems to be that forcing size to 1 gives
less weird behaviour for the application. So here that would be

   if (size == 0) {
       size++;
   }
   ptr = _aligned_malloc(size, alignment);

We don't need to do anything on the POSIX side (unless we want to
enforce consistency of handling the size==0 case).

I'd quite like to get this series in before softfreeze (though mostly
just for my personal convenience so it's not hanging around as a
loose end I have to come back to after we reopen for 7.1). Does anybody
object if I squash in that change and put this in a pullrequest,
or would you prefer to see a v2 series first?

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]