Re: [PATCH] lib/xz: replace min_t with min

[Lasse Collin]

 On 2026-06-10 Andrew Morton wrote:
> On Wed, 10 Jun 2026 16:23:23 -0700 Nathan Chancellor
> <nathan@xxxxxxxxxx> wrote:
> > These two hunks from this change in -next as 1003161e12ac ("lib/xz:
> > replace min_t with min") cause warnings in the arch/powerpc/boot
> > code, as it uses an old, simple version of min() and max() that
> > does not have the improvements done in d03eba99f5bf ("minmax: allow
> > min()/max()/clamp() if the arguments have the same signedness."):  
> 
> Well that's annoying.
> 
> A pleasing solution would be to make the xz code be more consistent
> in its type usage.  struct lzma_dec has a liking for uintXX_t whereas
> struct dictionary likes size_t.  Perhaps a fundamental reexamination
> of what these fields are representing is in order?

I tried to rethink it.

Callers use struct xz_buf to pass input and output buffers. That struct
uses size_t. I assume it should stay that way because the existing
callers assign size_t values to struct xz_buf members.

The input buffer members from struct xz_buf are assigned to members of
struct rc_dec, which is why size_t is needed in struct rc_dec.

In single-call mode (XZ_SINGLE), the decoder writes directly to the
caller-specified output buffer. In this case the output buffer members
from struct xz_buf are assigned to struct dictionary, and thus multiple
members in struct dictionary have to be size_t. In multi-call mode
(XZ_PREALLOC or XZ_DYNALLOC) the dictionary buffer is private to the
decoder and then uint32_t would suffice in struct dictionary.

Otherwise xz_dec_lzma2.c would be fine without size_t.

A few uint32_t uses could be changed to size_t to avoid the min()
issue, and slightly cleanup uint32_t vs. size_t usage otherwise too.
The first attached draft patch does this.

Even all uint32_t uses could be changed to size_t like in the second
patch, but it looks confusing in situations when a value isn't a size
or offset. It also increases the sizes of structs more.

I don't like the second patch, but I will submit the first one in a day
or two if I still think it's OK.

-- 
Lasse Collin