"The problem with C/C++ is that even someone who's been specifically trained to find buffer overflows has to CONSTANTLY check the lib docs"
-- @0xabad1dea
Blaming a traditionally trained C/C++ programmer for errors when made to parse complex input structures is shifting the blame to the victim.
Securely coding an ad-hoc input recognizer in C/C++ is possible, (look up DJB's Qmail and FX's Blitzableiter) but should not be regarded as a typical programming task. It is to programming what juggling knives is to cooking.
It's the ad-hoc recognizer jungle, inhabited by strange, chimaeric creatures. Listen, what is that painful, grinding, gritting sound? This is the sound of millions of ad-hoc C/C++ input handling routines painfully trying to recognize complex inputs. Every now and then, a crash, a thump of dumped core, a screech of a kernel panic, a wet plop of a BSOD; but the pain never ends.
Most C/C++ programmers feel this pain sympathetically and are disturbed by it. Some shrug it off, others who understand what memory corruption can do are scared, but all sufferers are told to deal with it and look to secure coding wizards for advice, and to accept the pain as part and parcel of their trade. Worse, they are never told exactly what that pain is, but treatment can only start with a diagnosis.
With LANGSEC, we diagnose this pain, put a name to it, and show the way to get rid of it.