Machte meinen Tag:
From: Georgi Guninski
Subject: [Full-disclosure] Linus mass killing integer overflows
the news is, the benevolant dictator has said “let there be C++”, and there is more secure, full featured, reliable and faster linux kernel written2 mainly in C++. the official release is scheduled for 2.8 or when redhat™ becomes ready for the desktop3, whichever comes first.
key improvements include:
a) integer overflows were PITA for the kernel janitors. once the classes SafeInt and SafeLong were implemented with suitable operators, the new kernel is 100% “int/long too big” free. the refactoring tool made this part easy.
b) some clever abuse of exceptions dramatically reduces the amount of OOPS:
cases like ‘(SafeInt)0=foo->bar()’ are now gracefully catch()ed, killing
c) kernel structures were just lame emulation of C++ objects. now they are native C++ objects.
d) exceptions result in cleaner, easier to read code and almost stop the nasty abuse of “goto”
currently there are discussions for implementing COM in the kernel and/or scripting the kernel from userland, but Linus hasn’t made up his mind yet.
the first public prerelease will be available from ftp://ftp.kernel.org/pub/linux/kernel soon.
My wishlist for 2.8:
-jvm (should boost my swing apps)
-sql support to query kernel table and fs data
-lisp and prolog interpreters (don’t have a use for this but I’m sure somebody will need it)
The kernel folks have taken a seriously wrong turn here. They should have delayed the preview release until the garbage collector was ready. That’s where the real value for these patches starts.
> My wishlist for 2.8:
> -jvm (should boost my swing apps)
agreed. i vote for implementing parrot – http://www.parrotcode.org/ to avoid
perl vs python vs java flames.
> -sql support to query kernel table and fs data
this seems a bad idea. what if a mcse discovers a sql injection in kernelspace? the side effects may be worse than a cake on b1l1.
> -lisp and prolog interpreters (don’t have a use for this but I’m sure
> somebody will need it)
rms likes lisp, so we can count on him.