The last time I worked with the DNS protocol, I seem to remember that everything had a well-defined (and small) limit on its size, and it wasn't really necessary to use dynamic allocation at all. Strings are length-prefixed, not null-terminated, and the longest length fields are only 16 bits.

A look at the RFC shows the strict limits on size:

https://www.ietf.org/rfc/rfc1035.txt

In comparison to text protocols like HTTP, I see far less opportunities to make errors like buffer overflows with DNS. It's a simple and relatively easy to parse binary protocol.

Prefixed strings can even be a source of buffer overflows, if you don't check if the length is smaller than the actual length of the rest of the data. In fact this was actually the source of the heartbleed bug.

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.

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.

"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

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.

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.

> 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.

    We clearly need more/better tooling in this area in C).

Note I'm not suggesting this is enough to make C safe.

Edit: A quick demonstration, based on 30 seconds with valgrind. If I run with ./bin/massdns --help, it makes a malloc() on line 595, then exits on 605 without free()ing. And yes I know this isn't really an issue in practice, but it demonstrates that the tools can see issues.

%x takes unsigned int, not a char. (Although I guess you could just rely on promotion here if you can rely on the unsignedness of char).

> Could you point out a line that is prone to integer overflows?

Never said that it was an overflow (just C&P that comment from the file). Just said its invalid use. Which I'm totally willing to agree on the compiler mostly getting correct behavior. Just not really something I'd want to see landing in something that we all need a really good, secure implementation of.

Best of luck though, I hope you iterate on this to the point we can have a really good DNS implementation in C, in user-space, with optional async processing.

If compilers did not do promotion, they would be very obviously not compliant with the C standard and unable to compile correctly most existing code, so I'm willing to bet that is something you can rely on. It's defined by the standard and widely used.