[LTP] [RFC] tst_assert: Use 'long long' to fix 32bit compat mode truncation

[Petr Vorel]

Hi all,

> Hi Andrea,

> On Thu, 24 Sep 2026 13:25:12 +0200, Andrea Cervesato wrote:
> > [PATCH 1/3] tst_assert: Use 'long long' to fix 32bit compat mode truncation

> --- [PATCH 1/3] ---

> > @@ -25,16 +25,17 @@ void tst_assert_int(const char *file, const int lineno, const char *path, int va

> >  void tst_assert_ulong(const char *file, const int lineno, const char *path, unsigned long val)
> >  {
> > -	unsigned long sys_val;
> > +	unsigned long long sys_val;

> > -	safe_file_scanf(file, lineno, NULL, path, "%lu", &sys_val);
> > +	safe_file_scanf(file, lineno, NULL, path, "%llu", &sys_val);

> > -	if (val == sys_val) {
> > +	if (val == (unsigned long)sys_val) {
> >  		tst_res_(file, lineno, TPASS, "%s = %lu", path, val);
nit: maybe we should print also sys_val.
> >  		return;
> >  	}

> > -	tst_res_(file, lineno, TFAIL, "%s != %lu got %lu", path, val, sys_val);
> > +	tst_res_(file, lineno, TFAIL, "%s != %lu got %lu",
> > +		path, val, (unsigned long)sys_val);
nit: and here maybe also print the raw value:
> >  }

	if (val == (unsigned long)sys_val) {
		tst_res_(file, lineno, TPASS, "%s = %lu (%llu)", path, val, sys_val);
		return;
	}

	tst_res_(file, lineno, TFAIL, "%s != %lu got %lu (%llu)",
		path, val, (unsigned long)sys_val, sys_val);

It would print sometimes unnecessary info:

shmctl03.c:26: TPASS: info.shmmin == 1 (1)
shmctl03.c:30: TPASS: INT_MAX <= shmmax (2147483647 <= 4294967295)
shmctl03.c:34: TPASS: /proc/sys/kernel/shmmni = 4096 (4096)
shmctl03.c:35: TPASS: /proc/sys/kernel/shmall = 4294967040 (1152921504606846720)

> Casting sys_val to (unsigned long) truncates values exceeding ULONG_MAX on
> 32-bit systems, causing false passes when (sys_val & 0xFFFFFFFF) == val and
> printing a truncated value on failure. Compare values without truncation
> using (unsigned long long)val == sys_val, and print sys_val with %llu on
> mismatch. Handling of 32-bit compat truncation for /proc/sys/kernel/shmall
> should be done in shmctl03.c instead of altering generic library assertions.

Hm, looking further into it, this really does a behavior change on 32 bit,
because tst_assert_ulong() now compares only the low 32 bits. E.g.
file which contains 4294967301 passes against an expected 5. I'm not really sure
we want this. If yes, it should be documented.

Kind regards,
Petr