Also, I like how this problem had a really simple solution all along
There really isn’t anything we can do to prevent memory safety vulnerabilities from happening if the programmer doesn’t want to write their code in a robust manner.
Yeah, totally, it’s all those faulty programmers fault. They should’ve written good programmes instead of the bad ones, but they just refuse to listen
Right, those devs with 20+ years C experience don’t know shit about the language and are just lazy. They don’t want to catch up with the times and write safe C. It’s me, the dude with 5 years of university experience who will set it straight. Look at my hello world program, not a single line of vulnerable code.
Yeah, for sure. Human error is involved in C and inertia too. New coding practices and libraries aren’t used, tests aren’t written, code quality sucks (variable names in C are notoriously cryptic), there’s little documentation, many things are rewritten (seems like everybody has rewritten memory allocation at least once), one’s casual void * is another’s absolute nono, and so on.
It has nothing to do with knowing the language and everything to do with what’s outside of the language. C hasn’t resembled CPUs for decades and can’t be reasonably retrofitted for safety.
This is an overstatement, definitely. C is one of the few (mainstream) languages where memory safety vulnerabilities are even possible. So if you batch C and C++ together, they probably cover more than 90% of all the memory unsafe cove written in last 50 years, which is a strong implication that they will contribute to 90% of memory vulnerabilities.
All that said, memory vulnerabilities are about 65% of all high implact vulnerabilities on Chromium project^1 and about 70% of vulnerabilities at Microsoft ^2.
Well, one of the most widely used that allows to do low-level stuff. The most widely used one is by far JavaScript but good luck making an OS or a device driver with it
Oh gawd. That would be so horrible! Is there a project o compile JavaScript to bytecode? With like LLVM? There must be, but I haven’t heard of it. I shouldn’t even say anything because I will be better off pretending it doesn’t exist.
I do this constantly. undefined: not retrieved yet. null: Error when retrieving. Makes it easy to reason about what the current state of the data is without the need for additional status flags.
In my first programming job, I would actually do code reviews by pausing my own work, pulling their branch and building it locally, then using debug mode to step through every changed or added line of code looking for bugs, unaccounted for edge cases, and code quality issues.
…I dont do that anymore, I now go “looks good to me” even on 10 line reviews.
I know this is a joke, but it you did that I would reject the pr with the reason of too many things at once. Reopen separate PR to refactor variable names. I actually constaly get people doing this and it’s dangerous exactly for the reason you’re joking about. Makes it easier for errors to slip in.
This will lead to change fatigue. People will rather not cleanup as they go anymore and just get the work done, with worse and worse code quality as a result.
I know you’re playing the straight man to a joke, but actually you can apply a linter, then tell GitHub to ignore the implied ownership history for the purposes of blame from that reclining pr. All such prs are massive and yet by virtue of the replayability of the linter it’s also very easy to ensure errors didn’t slip in when reviewing.
I know the original comment was about renaming all the variables, but that’s obviously deliberately absurd, so I’m using here a completely realistic example instead.
programmer_humor
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.