That's a common problem, certainly, but if we include the wider world of micros and minis, I'd bet that buffer overuns related to null-teminated strings (BLEAH!) are in the lead :-)
I once saw a report quoting Microsoft that half of all vulnerabilities were buffer overruns. I also saw a Dave Plummer YT (Dave's Garage) video recently, in which he said that MS programmers tended to coypu pasty code, rather than reuse. Do I spot a pattern? :-) On Tue., Mar. 29, 2022, 23:10 Charles Mills, <charl...@mcn.org> wrote: > Well, while we are digressing ... > > There was discussion earlier of the use of the equal sign for assignment > versus comparison. > > I am going to guess that THE most common cause of C/C++ program errors is > the mis-use of = for comparison. (The comparison operator in C and C++ is > ==.) In C if you code > > if (foo = 3) bar = 5; > > Then the compiler generates code to assign 3 to foo, test the result (3) > for truth (not 0) and then execute the conditional statement. The above has > the same effect as > > foo = 3; > bar = 5; > > If I am recalling the story correctly, a malicious programmer *almost* > succeeded in inserting code into the Linux kernel of the form > > if (uid = 0) ... > > The code appears to be testing the uid for 0, but in reality is making the > uid 0. Someone who know how to get to the code path could make themselves > into superuser. > > I like := for assignment, but I believe C eliminated the ambiguity of = by > choosing == for comparison, by analogy to all of the other 2-character > comparison operators (>=, !=, etc.).= > > Charles > > > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
