It's not that they're broken in themselves, it's that they've been added to a language that can't support them properly. People say, oooh, you must write exception-safe code. What they're saying is, there's a property the code needs to have, which a compiler cannot test for, which you can't even easily unit-test for. And without this property -- exception-safety -- the code is unsafe. (It's not the code that throws or catches exceptions that you need to worry about: it's routines whose callees might throw and whose callers might catch. Those routines have secondary control flows through them, ones you can't see, but which need to be correct for the program to be safe.)

It's not an innovation of the TDD community to say, that if something in your code isn't tested, you can't swear it works. In particular, you can't swear it will continue to work when future maintenance occurs. Because exception safety can't be "defended" against future breakage, I don't think you can hand-on-heart deliver C++ software written with exceptions and claim that it works.

I'm not against exceptions as a programming technique: I think they work great in managed languages such as Python, Java, or ML. In those languages, it's not possible to write code that isn't "exception-safe" in the C++ sense. That's where exceptions belong. Throwing exceptions through unmanaged code was a brave experiment on C++'s part, but it's a misfeature, and I've got more confidence in codebases which forbid that (despite whatever problems they have with two-stage initialisation) than codebases which don't.

Peter

Nor this http://survex.com/~olly/rheolism/: real Tetris in one line of BBC BASIC, 255 bytes after tokenisation. All the shapes are stored in one 32-bit constant. It's just amazing.

Peter

Since the first Iphone as such has become known as the "2G" and the second as the "3G", I suggest thinking of the Newton as the Iphone 1G. (OK, so there were a few different versions of the Newton itself. But at this distance in time, I think we can ignore that.)

Peter

Actually, it's not even really about whether developers individually get to choose the tools. It's about trying to gauge whether engineering as a whole has freedom to choose the tools, or whether it's imposed from above/outside. I've seen environments where literally the entire development team (including management) hates the source-control system, and the entire development plus QA teams (including management) hate the bug-tracking system, but corporate politics has left them with no mandate to get them changed against the wishes of the IT department. Perhaps that is indeed a rare pathology, but it's the one the question was intended to be diagnosing.

Peter

Yes. That's why, as I said, I suggest paying attention to how they reply, not to which actual products they name.

For one thing, an email client is one of the primary tools of most jobs today, even software development jobs -- though I agree that in fact few, maybe none, are actually unusable.

But yes, the purpose of the question is very much for the interviewee to determine whether "major demands" for tools that are needed to actually do the job, such as source-control (which is why I indicated a harder line on that) are listened to or not. (It's not, as you seem to have inferred, a recommendation to make such demands at interview.) At the level I'd be interviewing at, for instance, you'd be taking me on not just for my experience in the design of software, but for my experience in the design of software-development organisations. The suggestion of "Babe Ruth" tooling isn't born from some prima-donna fantasy, it's the result of my having worked in both kinds of environments and seen the efficiency advantages. So that's one free piece of advice for your organisation without you even needing to have hired me.

Peter

This (certainly the email and source-control bits) is an excellent question to ask -- not so much because of what the answer as such, but because of your interviewers' reaction to giving the answer. If the interviewers frown or are apologetic about the answers, then that's a big clue that the IT department is run for its own convenience rather than the users' convenience.

For instance, if the email system in use is Outlook, ask if they have IMAP or SIMAP turned on, to enable non-Exchange clients. If the answer is no, then you know that uniformity gets enforced over convenience. You also know that nobody in the company uses any external mailing lists (such as the GCC or Linux kernel lists), as there's no way of posting to those from Exchange without looking like a fool.

If your interviewers sound cross or apologetic when describing the source-control system -- in other words, if the source-control system was dictated by IT without engineering buy-in -- then decline the job. Even if it were theoretically possible to do work in such a company, the excess overhead due to dealing with bureaucracy would make it an inefficient use of your time.

The absolute best answer you could get here is the one a VP of engineering whom I once worked for gave to a compiler vendor whose products we didn't want. "Can't you enforce tooling?", they asked him. "No," he said, "we don't tell Babe Ruth how to hold his bat."

Peter

Look at those large islands to the west of the Canaries. They're labelled Magnae Insulae Beati Brandani Branziliae Dictae: St Brandon's Large Islands, Called The Branzillas. Branzillas? Nobody used -zilla to mean "large" before Godzilla, and it didn't become really popular until Mozilla. The whole thing is clearly a forgery by some 21st-century geek, probably a Terry Gilliam fan, trying to mock up a folk etymology of the name "Brazil". ;)

Peter

While dereferencing NULL is explicitly not permitted, pointer arithmetic on NULL is permitted, and dereferencing any non-NULL memory address is permitted.

Not any non-null memory address -- only one that points into an object. As there is no object whose address is the null pointer, the dereference is still undefined. And the compiler knows that.

Another way of looking at it is that tun->sk is equivalent to (*tun).sk, which is even more clearly undefined in C.

Peter

Technically, however, the C standard allows tun->sk to be a valid address, so removing the test is a semantically-invalid optimisation.

No. Technically, if tun is null, dereferencing it in the expression tun->sk invokes undefined behaviour -- not implementation-defined behaviour. It is perfectly valid to remove the test, because no strictly conforming code could tell the difference -- the game is already over once you've dereferenced a null pointer. This is a kernel bug (and not even, as Brad Spengler appears to be claiming, a new class of kernel bug); it's not a GCC bug.

But as other posters have said, it would indeed be a good security feature for GCC to warn when it does this.

Peter

It's a bit of a pain to explain why Firefox is the same thing as Ice Weasel.

"Because the Mozilla people have done something insane, egotistical, and counter-productive." There, that wasn't very painful.

As you imply, the reason that anyone who forks Firefox should be able to call the binaries their project produces firefox is the same reason that anyone who forks ls should be able to call the binary their project produces ls. Anything else just causes user confusion. If you want to have a trademark because you think you're so darn good that anyone else's version of your code just won't be the same, trademark your organisation name, not your project name. FSF Emacs vs XEmacs, FSF Glibc vs eglibc, coreutils ls vs BSD ls: there's no ambiguity in any of those cases.

By trademarking the name of the product, and imposing restrictions on uses of that trademark which affect people carrying out the normal processes of open-source natural selection, the Mozilla people have placed their own personal egos above the quality of the user experience. That's the sort of behaviour that open-source more usually comes as a blessed relief from.

That such restrictions on trademarked product names are allegedly compatible with open-source licences should be viewed as a bug in those licences, and Debian are absolutely right to call the Mozilla people on not being DFSG-free. If you want to pinpoint the moment they lost their way, it was when they trademarked "Mozilla" and named their foundation after it, and changed the mozilla tree so that it no longer built a binary called mozilla. If when they realised their "mistake" they'd changed the foundation name not the binary name, there'd be the Seamonkey Foundation's mozilla versus everyone else's mozilla, which would be perfectly straightforward, and they'd have generated much less ill will.

Peter

That's exactly the sort of dry wit their writers use.

My favourite The Economist moment:
http://www.avclub.com/articles/february-1-2006,1713/ (final letter)
http://www.avclub.com/articles/february-15-2006,1716/ (final letter)

Links maybe NSFW.

Peter

The mass market wants tick boxes, and customers wanted P4S. If you didn't have P4S, you didn't sell. It's sad and believe me it's true.

Right, it wouldn't have been so bad if the customers actually did want Plays-For-Sure. In fact, they just thought they wanted it -- or worse, perhaps we just thought they thought they wanted it.

Here is a story about Plays-For-Sure. The Rio Carbon was in some ways the poster child for Plays-For-Sure, and for Janus DRM: it was one of the players which Gates himself waved around at the launch event. I don't know how many we sold, but it was a lot. One day in late 2005, Microsoft accidentally revoked the Rio Carbon Janus licence. Or, rather, apparently, they rolled out a new version of the software in the Redmond DRM servers, which made WMP erroneously think that the Carbon licence had been revoked. Either way the effect was the same: for about six weeks until they pushed out a WMP hotfix, nobody anywhere in the world could transfer Plays-For-Sure protected content to their Rio Carbons. And during this six-week period, exactly five users noticed, one of whom was a former Rio employee. That tells you all you need to know about the extent to which consumers actually used or liked Plays-For-Sure.

What saddens me most is the thought of all the cool stuff that we could have implemented if we hadn't been wasting our time doing Plays-For-Sure.

Peter