[PATCH 4/9] auditsc: test below 0 on unsigned ino

[PATCH 4/9] auditsc: test below 0 on unsigned ino

[roel kluin]

ino is unsigned so the test didn't work.

Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index c10e7aa..dc8e0a4 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -286,7 +286,7 @@ static int audit_match_filetype(struct audit_context *ctx, int which)
 	mode_t mode = which & S_IFMT;
 	if (index >= ctx->name_count)
 		return 0;
-	if (ctx->names[index].ino == -1)
+	if (ctx->names[index].ino == -1ul)
 		return 0;
 	if ((ctx->names[index].mode ^ mode) & S_IFMT)
 		return 0;

Re: [PATCH 4/9] auditsc: test below 0 on unsigned ino

[Al Viro]

On Mon, Jul 21, 2008 at 08:29:16PM -0400, roel kluin wrote:
> ino is unsigned so the test didn't work.
                              ^^^^^^^^^^^

Kindly report the way to reproduce your remarkable observation.  Do not
forget to include the compiler version, since the following two lines

> -	if (ctx->names[index].ino == -1)
> +	if (ctx->names[index].ino == -1ul)

are equivalent.  -1 is an expression of type int.  ctx->names[index].ino
is an expression of type unsigned long.  If both operands of a comparison
operator have arithmetic types, the usual arithmetic conversions (see 6.3.1.8)
are applied to the operands.  In this case, both types are integer ones and
not modified by integer promotions.  One is signed, another is unsigned and
the rank of unsigned one is greater or equal to that of the signed one
(rank(unsigned long) = rank(signed long) > rank(signed int)).  Therefore,
the operand with signed integer type (-1) is converted to the type of
argument with unsigned integer type.  Then they are compared.

In the second case both operands have the same integer type (unsigned long)
and comparison is done without any conversions.

Proof that (unsigned long)-1 and -1ul have the same value (namely, the maximal
value that can be represented in unsigned long) is left as an exercise for
reader.

Assuming that you have indeed observed a case when results of these tests
differed, you have found a blatant non-compliance of whatever C compiler
you were using.  I am sure that maintainers of that compiler would like to
see your bug report, especially since you already have a reproducer.  So
would everybody else, to know which version to avoid.