lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 19 Jul 2006 20:13:22 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	ricknu-0@...dent.ltu.se
CC:	linux-kernel@...r.kernel.org, Andrew Morton <akpm@...l.org>
Subject: Re: [RFC][PATCH] A generic boolean

ricknu-0@...dent.ltu.se wrote:
> Citerar Jeff Garzik <jeff@...zik.org>:
>> Also, you don't want to force 'unsigned char' on code, because often 
>> code prefers a machine integer to something smaller than a machine integer.

> But isn't a bit smaller than a byte? Sorry, do not understand what you mean.

For all processors, it is generally preferred to have integer operations 
performed on a "machine integer."  A machine integer is the natural data 
type of the processor.  If it's a 32-bit processor, the natural data 
type for the ALU is a 32-bit int.  If it's a 64-bit processor, the 
natural data type for the ALU is a 64-bit int.  [though, for some 64-bit 
processors, a 32-bit int may be best for the situation anyway]

As such, the compiler and/or CPU must do more work, if an operation such 
as a bit test is performed on a data type other than a machine int.

Consider for example ARM or Alpha architectures, which may not have 
instructions 8-bit unsigned char integers.  The integers have to be 
_converted_ to a machine integer, before the operation is performed.

It is for this reason that you often see boolean implemented as 'int' 
rather than 'unsigned char'.  'int' is much more "natural", when you 
consider all the architectures Linux must support.

The best solution is to typedef 'bool' to the compiler's internal 
boolean data type, and then update code to use 'bool'.  Then all these 
issues magically go away, because you never have to care what the 
compiler's underlying boolean data type is.

	Jeff




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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ