[PATCH] C undefined behavior fix

[Linus Torvalds]

On Sat, 5 Jan 2002 dewar@gnat.com wrote:
>
> Let me say once again that what is important is for the Linux kernel folk
> to clearly document what they are depending on, and the code should also
> make clear the points at which the code is relying on implemenation
> defined things (ideally such things should be clearly isolated in the code).

Most of the time we try to avoid any gray areas. But

 - there's closer to 4 million lines of code there. MOST of which is
   device driver stuff, written by thousands of people of varying levels
   of knowledge of C. You can draw your own conclusions..

 - there's a fair amount of code, especially in networking, which tends to
   access the same data as different types (ie a packet can be both just
   "anonymous packet" or "TCP header" or whatever), and the type-based
   aliasing really didn't work for that at all. Thus the kernel disables
   it.

 - most of the "core" code is actually fairly standard ANSI C, to the
   point of religiously using the C type system with as much typechecking
   as possible. There are NOT that many issues there, most of the time.

   Aside: in this area, type-based alias knowledge would probably be fine,
   so it's kind of sad that we had to disable it because there was no good
   way to just locally disable it.

 - one big thing is the very fundamental issue of memory management. I
   suspect it's not any more hairy than what you'd find in something like
   a debugging "malloc()" library, but it's certainly not trivial, and can
   be quite involved (ie knowledge of "mapping" physical pages temporarily
   into virtual kernel space through the TLB, and as a result there's
   actually quite a lot of "unsigned long"<>"void *" conversions).

The other "special" area is the one where the strcpy() came from:

 - early bootstrapping is different, and is a separate issue for all
   architectures. There's a lot of code that runs with only partial
   mappings present, for example - because the full kernel mappings
   haven't even been built up. Again, there's a _lot_ of mixing of integer
   and pointer information at this point, and there can be data structures
   that are built up by the compiler/linker.

The good thing about the bootstrapping stage is that if things break, they
don't tend to break subtly. It either works or it doesn't. It's a total
bitch to debug when it doesn't, but it doesn't have some of the _really_
nasty problems (disk corruption, security issues, what-not) that the
proper kernel execution has.

		Linus