mpi reminded me of this diff.
On Tue, May 14, 2019 at 01:51:05PM +, Miod Vallat wrote:
> This tries to keep diffability against upstream, hence a questionable
> choice of the size type for zcfree() - but all sizes should fit in 32
> bits anyway.
>
> Since all zcfree routines used in the tree
> From: Miod Vallat
> Date: Tue, 14 May 2019 17:09:36 - (UTC)
>
> > I have serious doubt whether the whole "plan" for using the sizes to
> > change the malloc implementation is feasable. The drm(4) code for
> > example relies on emulation of Linux memory allocation APIs to keep
> > the diffs
> I have serious doubt whether the whole "plan" for using the sizes to
> change the malloc implementation is feasable. The drm(4) code for
> example relies on emulation of Linux memory allocation APIs to keep
> the diffs small and jsg@ and myself sane. Most of these APIs don't
> pass sizes in the
> Date: Tue, 14 May 2019 13:51:05 +
> From: Miod Vallat
>
> This tries to keep diffability against upstream, hence a questionable
> choice of the size type for zcfree() - but all sizes should fit in 32
> bits anyway.
>
> Since all zcfree routines used in the tree cope with NULL arguments
> (
This tries to keep diffability against upstream, hence a questionable
choice of the size type for zcfree() - but all sizes should fit in 32
bits anyway.
Since all zcfree routines used in the tree cope with NULL arguments
(including the various alloc.c used by the boot blocks), I have
simplified TR
