On 12/31/12 8:10 PM, Marcus G. Daniels wrote:
On 12/31/12 1:44 PM, Paul D. Fernhout wrote:
So, it was a meta-bug in that sense about an unexpected meaning shift
when a number leaked beyond a boundary that was supposed to contain it.
[..]
I'm not sure what sort of automated systems could deal with that kind
of unexpected semantic shift? Still, for that one case, probably one
could come up with a way of defining symbols that could not leak
across boundaries because of compiler checks or using public/private
typed aspects of languages to do that (like for example even in Java
where you had a public enum for error codes to return to user space,
but a different private enum for internal state). In practice the C
language the Linux kernel is written in may not make that easy to
enforce programmatically though.
>
Yup. Add more opaque types in the kernel implementation so that a type
conversion (to the POSIX semantics) _must_ occur. GCC recently
converted to compiling itself in stricter C++ mode, and the world did
not end. In spite of advice such as..
http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918
That was a link to Linus Torvald's rant on why he thinks C++ is a
"horrible" language. :-)
That issue is also discussed in comments here:
http://developers.slashdot.org/story/12/08/15/1338212/gcc-switches-from-c-to-c
http://news.slashdot.org/story/12/12/23/1945248/gnu-grep-and-sed-maintainer-quits-rms-and-fsf-harming-gnu-project
Especially (a thread from the second link):
http://news.slashdot.org/comments.pl?sid=3336085&cid=42376847
But frankly, if C++ had just specified name mangling (and some related
things) so linker worked consistently, I think C++ would have taken over
from C fairly completely. That is the main thing that held it back IMHO,
that you could not consistently and easily link C++ code like you could
C code. Related:
http://en.wikipedia.org/wiki/Name_mangling#Standardised_name_mangling_in_C.2B.2B
"While it is a relatively common belief that standardised name mangling
in the C++ language would lead to greater interoperability between
compiler implementations, such a standardization by itself would not
suffice to guarantee C++ compiler interoperability and it might even
create a false impression that interoperability is possible and safe
when it isn't. Name mangling is only one of several application binary
interface (ABI) details that need to be decided and observed by a C++
implementation. Other ABI aspects like exception handling, virtual table
layout, structure and stack frame padding, etc. also cause differing C++
implementations to be incompatible. Further, requiring a particular form
of mangling would cause issues for systems where implementation limits
(e.g., length of symbols) dictate a particular mangling scheme. A
standardised requirement for name mangling would also prevent an
implementation where mangling was not required at all — for example, a
linker which understood the C++ language. The C++ standard therefore
does not attempt to standardise name mangling. On the contrary, the
Annotated C++ Reference Manual (also known as ARM, ISBN 0-201-51459-1,
section 7.2.1c) actively encourages the use of different mangling
schemes to prevent linking when other aspects of the ABI, such as
exception handling and virtual table layout, are incompatible.
Nevertheless, as detailed in the section above, on some platforms the
full C++ ABI has been standardized, including name mangling."
So, I guess another meta-level bug in the Linux Kernel is that it is
written in C, which does not support certain complexity management
features, and there is no clear upgrade path from that because C++ has
always had serious linking problems.
Well, Linus is a smart and creative guy, and just like he designed git
as a successor to BitKeeper for Linux kernel development, maybe he will
design a better successor to C? Of course, many have tried -- including
people on this list... It obviously is not easy for many reasons
(including social network effects). But, socially, Linus perhaps could
pull it off same as with git now taking over the DVCS world? If he were
to do such a thing, what could FONC offer in that direction?
--Paul Fernhout
http://www.pdfernhout.net/
====
The biggest challenge of the 21st century is the irony of technologies
of abundance in the hands of those thinking in terms of scarcity.
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
