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]

Message-ID: <OFE9F7159D.A4D62F91-ONC125772F.005CB786-C125772F.00603B6C@transmode.se>
Date:	Wed, 26 May 2010 19:31:06 +0200
From:	Joakim Tjernlund <joakim.tjernlund@...nsmode.se>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-next@...r.kernel.org,
	Stephen Rothwell <sfr@...b.auug.org.au>
Subject: Re: linux-next: build warning in Linus'tree

Linus Torvalds <torvalds@...ux-foundation.org> wrote on 2010/05/26 18:46:11:
>
> On Wed, 26 May 2010, Joakim Tjernlund wrote:
> >
> > 1) It silently breaks when neither of {__LITTLE_,__BIG}_ENDIAN (or both)are
> >    defined depending on the endianess of the target CPU.
> >    The glibc model generates a compile error if you forget to include __BYTE_ORDER.
>
> Umm. Except when it doesn't (yes, Linux has the "Wundefined" thing, and
> has had for a long time). I've seen the glibc model do the wrong thing
> exactly because traditional C semantics is "undefined symbol is 0 in
> evaluations"
>
> Try compiling this
>
>    #include <stdio.h>
>
>    #if NOT_HERE == NOT_THERE
>    int main()
>    {
>       printf("Hello world!\n");
>    }
>    #endif
>
> and even with -Wall it compiles perfectly happily.

Ouch! But here -Wundef really helps.

>
> So no. The glibc model is _not_ any better in practice.

In the kernel it is since it breaks the compile. The breakage
my patch introduced is a sign of that, right?

>
> > 2) It clashes with user space so one cannot use it in exported header files.
>
> Which is annoying, I agree. But you shouldn't generally use kernel headers
> for user space anyway, much less export anything that is byteorder-

Not in general, but my case could have been avoided, I sure there are others
too. Why else does some header files bother with __BYTE_ORDER?

> specific. So anybody who has this problem is likely doing something iffy
> to begin with.

hmm, so then I guess the existing use of __BYTE_ORDER in the
kernel should be removed?

>
> Besides, you can solve it cleanly by simply avoiding the crazy glibc
> semantics entirely. IOW, the CONFIG_BIG_ENDIAN option I suggested (and

CONFIG_BIG_ENDIAN would have helped me with my lib/crc32.c problem
but it does not prevent silent breakage so I figured the glibc model
would be better.
Is it such a big difference, readability wise, between
  #ifdef CONFIG_BIG_ENDIAN
and
  #if __BYTE_ORDER == __BIG_ENDIAN
that you rather risk silent breakage?

> again, you should damn well not export things that depend on it to user
> space - there are architectures where user-space might be switchable)

Such arch exists but does any of them run linux in both modes?

  Jocke

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