linux-kernel - Re: [RFC][PATCH] A generic boolean (version 2)

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 21 Jul 2006 20:27:37 +0200
From:	Michael Buesch <mb@...sch.de>
To:	Jan Engelhardt <jengelh@...ux01.gwdg.de>, ricknu-0@...dent.ltu.se
Cc:	linux-kernel@...r.kernel.org, Andrew Morton <akpm@...l.org>,
	Jeff Garzik <jeff@...zik.org>,
	Alexey Dobriyan <adobriyan@...il.com>,
	Vadim Lobanov <vlobanov@...akeasy.net>,
	Shorty Porty <getshorty_@...mail.com>,
	Peter Williams <pwil3058@...pond.net.au>
Subject: Re: [RFC][PATCH] A generic boolean (version 2)

On Friday 21 July 2006 16:23, Jan Engelhardt wrote:
> >The changes are:
> >* u2 has been corrected to u1 (and also added it as __u1)
> 
> Do we really need this? Is not 'bool' enough?

I would say we don't even _want_ this.
A u1 variable will basically never be one bit wide.
It will be at least 8bit, or let's say 32bit. Maybe
even 64bit on some archs. It all depends on the compiler
plus the arch.

We _don't_ want u1, because we don't get what we see.
If we say u8 or u32, we get an 8bit wide data type and
a 32bit wide type. But we _don't_ get a 1bit wide
type for u1. We get something undefined.

Consider:

struct device_control_buffer {
	u1 device_is_fooing;
	u32 foodata;
} __attribute__((packed));

This would not lead to the expected results.
It's horribly broken, obfuscating and misleading.

-- 
Greetings Michael.
-
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/