linux-kernel - Re: linux-next: build warning in Linus'tree

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:	Wed, 26 May 2010 08:26:04 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
cc:	Joakim Tjernlund <joakim.tjernlund@...nsmode.se>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-kernel@...r.kernel.org, linux-next@...r.kernel.org
Subject: Re: linux-next: build warning in Linus'tree



On Tue, 25 May 2010, Andrew Morton wrote:
> 
> > I suspect fixing this entails moving all endian tests to #if __BYTE_ORDER ...
> > and then always define both __LITTLE_ENDIAN and __BIG_ENDIAN
> 
> Yes we can't define __LITTLE_ENDIAN to anything on big-endian without
> breaking lots of other things.

Indeed. The whole glibc thing of doing

	# if __BYTE_ORDER == __BIG_ENDIAN

(see "grep ENDIAN /usr/include/*") is a f*cking idiotic. It is way less 
readable, and insane to do. I guess it's some traditional unix disease.

The way to do it in Linux is to just do

	#ifdef __{BIG,LITTLE}_ENDIAN

which is a lot more readable. 

If anybody wants to change that, they still shouldn't change it to the 
idiotic glibc model. If you want it to be more readable, maybe somebody 
can introduce a CONFIG_{BIG,LITTLE}_ENDIAN{_BITFIELDS}

			Linus
--
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/