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

[Andrew Morton <akpm@linux-foundation.org>]

On Wed, 10 Jun 2026 16:23:23 -0700 Nathan Chancellor <nathan@kernel.org> wrote:

> On Tue, Jun 09, 2026 at 06:00:28PM +0300, Lasse Collin wrote:
> > From: Thorsten Blum <thorsten.blum@linux.dev>
> > 
> > Use the simpler min() macro since the values are unsigned and
> > compatible.
> > 
> > Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> > Reviewed-by: Lasse Collin <lasse.collin@tukaani.org>
> > Signed-off-by: Lasse Collin <lasse.collin@tukaani.org>
> ...
> > diff --git a/lib/xz/xz_dec_lzma2.c b/lib/xz/xz_dec_lzma2.c
> > index 4b783ac94e71..9d80342b9c6b 100644
> > --- a/lib/xz/xz_dec_lzma2.c
> > +++ b/lib/xz/xz_dec_lzma2.c
> > @@ -354,7 +354,7 @@ static bool dict_repeat(struct dictionary *dict, uint32_t *len, uint32_t dist)
> >  	if (dist >= dict->full || dist >= dict->size)
> >  		return false;
> >  
> > -	left = min_t(size_t, dict->limit - dict->pos, *len);
> > +	left = min(dict->limit - dict->pos, *len);
> >  	*len -= left;
> >  
> >  	back = dict->pos - dist - 1;
> > @@ -1098,9 +1098,8 @@ enum xz_ret xz_dec_lzma2_run(struct xz_dec_lzma2 *s, struct xz_buf *b)
> >  			 * the output buffer yet, we may run this loop
> >  			 * multiple times without changing s->lzma2.sequence.
> >  			 */
> > -			dict_limit(&s->dict, min_t(size_t,
> > -					b->out_size - b->out_pos,
> > -					s->lzma2.uncompressed));
> > +			dict_limit(&s->dict, min(b->out_size - b->out_pos,
> > +						 s->lzma2.uncompressed));
> >  			if (!lzma2_lzma(s, b))
> >  				return XZ_DATA_ERROR;
> >  
> 
> 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?