If true, g++ is broken and needs to be fixed.

You are certainly insistent about the badness of that missed return statement :) But it is certainly not true that in plain C such a bug can only cause data corruption (if that were even desireable); just imagine the consequences if the return value is a pointer...

What is the language design problem, and is there a better solution than RAII?

Well, C++ was never a "preprocessor". Cfront was always a full-fledged compiler albeit the output was not native assembler but C code. The Comeau C++ compiler works on the same principle. There is no need for C compatibility in the language in order to do this though.

When Stroustrup says C compatibility was crucial for its success, it is your final sentence that's relevant: the userbase was originally very small, and they basically demanded C compatibility. In "Design and evolution", Stroustrup explains how he eg tried to fix function declaration to something saner, but his audience threatened to walk-out on him if he did, so he was basically forced to cater to their whims because otherwise the language would be dead.

Without actually having read the "why C++ sucks" argument, I tend to agree that C compatibility was not necessarily a good thing, even if pragmatic.

1. Undefined behavior does not mean that a compiler is supposed to stop with an error. In fact, it means that the compiler should accept the code, but that the standard does not mandate any particular behavior in the code that is generated.
2. This is not equivalent to saying that a function which declares a non-void return type must have at least one return statement.

A compiler is certainly not required to stop with an error, but it is perfectly legal for it to do so:

"1.3.12 undefined behavior
behavior, such as might arise upon use of an erroneous program construct or erroneous data, for which this International Standard imposes no requirements. Undefined behavior may also be expected when this International Standard omits the description of any explicit definition of behavior. [Note: permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message)."

Perhaps you are thinking of unspecified behaviour?

What you are saying is not correct. The C++ standard says:

"6.6.3 The return statement
[...]
A return statement without an expression can be used only in functions that do not return a value, that is, a function with the return type void, a constructor (12.1), or a destructor (12.4).
[...]
Flowing off the end of a function is equivalent to a return with no value; this results in undefined behavior in a value-returning function."

It is perfectly legal for a compiler to issue a warning for this or even an error. I consider a compiler refusing to compile it a superior compiler.

Thanks for stepping up and fielding the question for me :) Japanese already has a phonetic alphabet (well, syllabary) that is very well suited to write Japanese in the kana. Problem is, only small children write exclusively with it. To appear at all literate, kanji is certainly needed. It's actually a lot easier to read a Japanese text if there is kanji, as long as one knows the kanji in question.

You are completely ignorant of both runes and kanji if you think them similar, and that runes fell out of use because the latin alphabet is "superior".

eFuses are not affected by UV light; perhaps you're thinking of EPROM, a completely different technology?

An efuse is a physical alteration of the circuit. An FPGA uses SRAM or flashrom to hold the logic. Coming from PS3, I don't know anything about this Motorola phone, but I do know that people throw around the magical "efuse" whenever something happens that they don't understand. Example: "Sony prevented downgrades with firmware 2.10" -"OMG, they've blown an EFUSE!!" From reading the brief of the previous story, this seems very much like one of those instances...

HAM didn't work quite as you describe. Six bits per pixel were used. The top two bits decided the operation according to: 00: bits 0-3 decides pixel value direct by indexing into the color palette 01: The pixel immediately to the left is copied and the blue component is replaced by bits 0-3 10: The pixel immediately to the left is copied and the red component is replaced by bits 0-3 11: The pixel immediately to the left is copied and the green component is replaced by bits 0-3 The palette also need not be fixed but could be replaced mid screen, as could the resolution. The Amiga had four non-pannable PCM audio channels: two fixed to the left audio output and two to the right. The Amiga blitter could be used for rendering filled vectors, although not in the most efficient manner since it required line-drawing first, followed by a copy and fill.

Maybe check out the demo scene where 512-byte, 1k, or 4k productions are common?

Well... NASA has never lost any space probes due to software bugs, right?

And OpenBSD has only had two remote holes ("Only" two?) in the default install (with nearly all services turned off).

Avionics industry is doing better, but check out the requirements on them ( http://en.wikipedia.org/wiki/DO-178B )
If this is to be followed for all software, well, something is certain: costs and development time will go up.
In my limited experience, the wish is rather for these to go down even further, with more impossible deadlines ever coming up...

I'm not sure what you are complaining about exactly? DRI is an architecture, and one that couldn't support the features nVidia wanted. So they invented their own and hooked that into X. Is your complaint that they didn't make this achitecture open to all?

Well, it is maybe not the best counter-example to a rule "novels are unfilmable" as much as it was an extreme example because LR is simply a mastodont work any way you cut it, and yet it was successfully (at least at the box office) turned into film.

Now, I didn't like the films, particularly from the second half of the second film and onwards, but this is not because the book is decidedly "unfilmable"; it's simply because I think Peter Jackson is a poor director.