Generally agree, (and that's what we usually do in GLib). However, for a general purpose DNS user-space implementation I think it would be good to have something that can be used in both scenarios.

That's a coherent argument, but that argument is also, I think, probably responsible for virtually all of the exploitable offset-from-NULL vulnerabilities shipped in C code.

Unless, of course, one can recover from malloc failing.

Even if you can in theory, it's still a bad idea to try to do that. Statistically speaking, you will get it wrong.

It may be a bad idea for an average developer to try it, sure. Plenty of advanced things fall in to that category though.

It is a bad idea for any developer to try it. Statistically speaking, it is the best programmers who create the most widespread security flaws.

Which statistics are you referring to?

Well, there can't be any objective quantification of "best", so it's impossible to prove this without being subjective. But the most widespread vulnerabilities tend to be in software that a lot of people use. Software that a lot of people use is usually written by good programmers, because good programmers (for typical definitions of "good") are the most productive ones.

The people who write the Linux kernel, for example, are by and large good programmers, because kernel programming is difficult and becoming a prolific contributor even more so. They've been responsible for the majority of the security bugs in the Linux kernel. That doesn't make them bad programmers.

Correlation vs causation.

Good programmers work on popular software because most people work on popular software.

Most security bugs are found in popular software because most people care about (use, audit, exploit) popular software.

Nothing here backs the assertion that good programmers are more likely to create more bugs per line of code written.

I'd argue that the reverse is most likely true. Good programmers know their limits, the limits of their tools, and have the experience to recognize problematic patterns.

Saying no one should try to recover from allocation failure is like saying no one should attempt surgery because only surgeons kill people occasionally during operations.

  > Nothing here backs the assertion that good programmers 
  > are more likely to create more bugs per line of code 
  > written.

This is moving the goalposts. Here's your original statement:

"It may be a bad idea for an average developer to try it"

And here's pcwalton's rebuttal:

"It is a bad idea for any developer to try it"

The relative frequency of bugs between average developers and advanced developers isn't the issue. Very good developers create bugs that lead to security flaws all the time. That the number of bugs they create is less than the number of bugs that would be created by less experienced developers does not matter in this context, because we have empirical evidence that both these numbers are very far from zero.

  > Good programmers know their limits, the limits of 
  > their tools, and have the experience to recognize 
  > problematic patterns

Sharing such experience is precisely what tptacek and pcwalton are doing here.

I didn't move the goalposts very far at all. If you quoted the rest of pcwalton's comment you would have had a more appropriate context in which to understand my reply.

Here we have a claim that encompasses 100% of a population, which is refuted by someone in that population who doesn't agree with the claim (and whose direct experience contradicts it).

And it isn't just my experience which contradicts it. Many of my colleagues would dismiss such an assertion as well.

Now if his claim was about "many" or even "most" programmers then sure, perhaps there is nothing to refute. But then his claim would have added almost nothing to what he replied to.

Saying all? That's either a dramatic device which I don't think adds to a healthy discussion, or a genuine belied that I think should be refuted since I'm in a position to provide counter evidence.

> Nothing here backs the assertion that good programmers are more likely to create more bugs per line of code written.

That isn't what I said. I said that good programmers create more bugs on the whole.

> Saying no one should try to recover from allocation failure is like saying no one should attempt surgery because only surgeons kill people occasionally during operations.

We need surgery so that people don't die. You probably don't need to recover from malloc failing.

> > Nothing here backs the assertion that good programmers are more likely to create more bugs per line of code written.

> I said that good programmers create more bugs on the whole.

Well if good programmers write more code, then sure, that follows quite nicely. If you don't normalize for lines of code written, though, then I'm not sure I follow what the point of that assertion is.

If a good programmer writes 10x the code but 1.5x the bugs, I don't think it's fair or meaningful for this discussion to claim that the good programmer created more bugs on the whole.

> We need surgery so that people don't die. You probably don't need to recover from malloc failing.

Software definitely runs in places where lives can be affected and lost.