So you're saying C is a great language until you have to parse XML.
... exactly.
... exactly.
- don't use XML for anything;
- use the correct tool for the job, but first define the problem better. What was XML-RPC attempting to solve?
That's an excellent question! To answer it, we need to rewind to the year 1998. Nobody had ever heard of JSON (2002) or REST (2000) or SOAP. If you wanted to do remote procedure calls, you needed to use Sun RPC or Corba or another binary RPC stack. Some of these required tens of thousands of lines of C code to implement, and I don't even want to think about the security issues.
Basically, XML-RPC was trying to be REST+JSON before that was a thing. It had already been implemented for most scripting languages, but one of my consulting clients needed a C implementation to interoperate, so I wrote xmlrpc-c in a couple of busy weeks around the end of 2000, I think.
Back in those days, XML had a very clear 30 page spec and XML-RPC had a 2 page spec. If you want to argue that I was wrong to use C to implement 32 pages of pretty good specs, or that I was wrong to use the best off-the-shelf XML parser of the day, well, I agree. But I think we need to demand more from our system languages.
But people had heard of S-expressions, which are far more appropriate for data transfer than XML.
And the canonical S-expression spec, from 1997, is rather less than 30 pages: http://people.csail.mit.edu/rivest/Sexp.txt
Then you add the inefficiencies of XML encoding, and the utterly crappy nature of most XML translation layers . . . yeah, really easy to see the train wreck coming.
If C isn't up to implementing an only slightly complicated network protocol, it's not much of a systems programming language, is it?
It turns out, C is fine for writing such systems and getting them working fairly well, but very poor at making them really reliable and secure, and that's no longer a good tradeoff.
He considers that a positive feature, not a bad thing. You're the inverse.
I can see both sides of that tbh. It's a justifiable - but myopically idealistic - point.
But man he's being a pretentious ass about it.
If C is that bad at managing complexity (and complexity doesn't only arise from bad design choices, some problems are inherently complex) then it should be used as rarely as possible, period.
It's not about idealism, it's about ill-placed, almost comical elitism ("C is a low-level-hacker language and only real programmers use it" while a 3rd grader could understand pointer arithmetic) to the point of rather spending 5 days writing bug-ridden code in C instead of 5 minutes in whatever else, just because it's the right way.
It's ridiculous.
This, in my opinion, is why even if C were somehow free of buffer/integer overflow, UAF, and other vulnerabilities, it would still be a poor choice for many real-world (read: complex) applications.
Bingo, give the man a prize! As we say on UNIX: C gives one enough rope to hang oneself. It is expected one knows what one is doing, but in return, one gets complete control and infinite flexibility. No programming language can compensate for bad architectural decisions, or an absence of such decisions, or absence of insight. Such a programming language does not yet exist, and it is questionable whether it ever will. So yeah, you got exactly what I was trying to say.
Now, back to C: nobody, including me, has all the solutions, but from experience, I have some tips when writing C code:
run the damn thing you're building through a debugger; feed it all kinds of garbage while doing so; try to break it in every way, shape, or form you can think of. As the author of the program, one should have unique and powerful insights into where the weak points are. And after all of that is done and fixed, have someone completely unrelated to it try to break it. This last piece of advice is good for any language.
I have a friend. I'd beat the daylights out of my programs, break them every which way, fix all the bugs I could find, then I'd let him have at it. He'd usually break my program in 15 - 25 seconds. Then the cycle would repeat, until he could no longer break anything. At that point, we had something remotely resembling stable software. And a lot of those programs I had him break weren't even written in C!
One of the best techniques I found while developing in both assembler and C: run the program you're working on through the debugger as you're writing it. As soon as I write a new function, I fire up a debugger (or shell tracing, or...) One wouldn't believe how many bugs I've found and fixed before the program saw the light of day. And it saves so much time, even though that's completely counter-intuitive.
This just made me laugh. I'm not making a value judgement about your statement, I neither agree nor disagree.