Re: [PATCH 2.6.18-rc4-mm3 1/2] fs/cifs: Converting into generic boolean

From: Richard Knutsson
Date: Mon Sep 04 2006 - 08:23:30 EST


Sorry for the late reply.

Steven French wrote:

If bool is really more efficient (not just better for typechecking at compile time), I don't mind checking in a set of such changes post 2.6.18

Efficient how? Memory, cpu-cycles, man-hours? The latter I think is quite hard to prove one way or the other.
The first two depends on the compiler and its settings. I prefer a small memory-consumption so there is less swapping, others try to pull out every possible cpu-cycle. Giving the compiler information about what type we are really using, should let it make the result more efficient in either our preference, then any micro-optimization.
Also statements like:
a = !!b;
can be optimized to just plain:
a = b;


Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com

Richard Knutsson <ricknu-0@xxxxxxxxxxxxxx> wrote on 09/01/2006 08:42:58 AM:

> Jan Engelhardt wrote:
>
> >>--- a/fs/cifs/asn1.c 2006-09-01 01:24:45.000000000 +0200
> >>+++ b/fs/cifs/asn1.c 2006-09-01 02:43:09.000000000 +0200
> >>@@ -457,7 +457,7 @@ decode_negTokenInit(unsigned char *secur
> >>unsigned char *sequence_end;
> >>unsigned long *oid = NULL;
> >>unsigned int cls, con, tag, oidlen, rc;
> >>- int use_ntlmssp = FALSE;
> >>+ int use_ntlmssp = false;
> >> > >>
> >
> >Should not this become 'bool use_ntlmssp'? Possibly in a later patch?
> > > >
> I would like to, but there has been complaints on changing 'int''s into
> 'bool''s, so until there is a more formal decision on this...
> Of course I would be happy to make a 'int'->'bool'-patch if a maintainer
> wants it.
>
> >
> >Jan Engelhardt
> > > >
> Richard Knutsson
>



--
VGER BF report: U 0.46053
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/