The conversation

robomartinHNSource author
Lessons learnedExperience excerpt · English

I started programming back in the 8080, 8085, 6502, etc

… I started programming back in the 8080, 8085, 6502, etc. days. I had to program some prototype computers using a hex keypad while entering raw machine code (not even assembler). I still own a couple of these: https://i.imgur.com/ZsIJj1p.png In a couple of cases I had to take this approach to bootstrap Forth on a 6502, then write a full Forth code editor and finally write the robotics application from there. Do not confuse bad programming or lack of knowledge with something attributable to a language, any language. A knowledgeable software developer, among other things, stays clear of these issues. This is also the value of experience and exposure to a wide range of technologies. It's like blaming MicroPython for a machine getting destroyed because garbage collection interrupted a critical real time process. There's nothing wrong with MicroPython in that regard, the programmer/designer of the embedded system either lacked knowledge and understanding. Part of the problem, as I see it, is that a good deal of modern university CS degrees don't even touch low level stuff. …

Original discussionC Strings and my slow descent to madness322 source comments · at import
5

What was this responding to?

Parent context · original excerpt

NN
nneonneoHN

Pop quiz, which of these is safe, given "char buf[80]" and arbitrary user input in argv[1]? gets(buf); scanf("%s", buf); strcpy(buf, argv[1]); scanf("%80s", buf); strncpy(buf, argv[1], 80); snprintf(buf, 80, argv[1]); ---- The delightful answer is none of them . The first three have no bounds checking at all, meaning that they will happily overflow the buffer to an arbitrary extent (gets, at least, will usually trigger a warning on modern compilers). The next two have off-by-one errors, meaning that they will happily write a NUL byte out of bounds (and that's exploitable! https://googleprojectzero.blogspot.com/2014/08/the-poisoned-... ). The last one uses the right buffer length, but treats user input as a format string and can leak memory contents or produce arbitrary memory corruption with the %n format specifier. C string handling practically invites off-by-one errors and horr…

Full original

Community replies 0

No community replies yet. Add your perspective.

Replies from the source 5

Direct replies available in this import. Original-language excerpts.

SK
skribantoHN

One could take a glance at these and easily believe that they do the right thing. I don’t think that no one would accidentally miss such a small error from time to time.

Full original
IM
imtringuedHN

>Do not confuse bad programming or lack of knowledge with something attributable to a language, any language. In C everyone starts out as a "bad programmer". In other languages people are merely inexperienced. >however, someone with deep-rooted experience in these languages who jumps into C is very likely to do some truly horrific things. The language isn't the problem, at all. You are contradicting yourself.

Full original
JI
jiggawattsHN

> A knowledgeable software developer, among other things, stays clear of these issues. This is the "no true scotsman" fallacy. Languages can be designed so that less than perfectly knowledgeable programmers fall into the pit of success, or they can be designed so that they fall into the pit of failure. For people making your argument, I like to provide this challenge: Go take a flight on a 737 MAX that hasn't had its MCAS fixed/disabled. That should be fine, right? After all, not "true" pilot ought to disregard one sentence on page 437 of the flight manual that they weren't even given during a 1 hour training video, right? A true professional pilot memorises the engineering blueprints, the source code of the avionics, and the wiring schematics, right? So you have nothing to fear! The plane is "safe", and pilots can be trusted to be knowledgeable. Go buy that ticket.

Full original
KY
KyeRussellHN

God, this attitude reeeallllyy grinds my gears. This is precisely why C has outstayed its welcome in so many areas of software development. Every time some kid looking for a self-confidence boost buys into the idea that using a language with a minefield of archaically-named string manipulation functions somehow makes them a ‘real’, ‘smart’, developer, we are all left a little worse off. No, it’s not the fault of the language’s design. It’s not even the fault of history - the fact that C was conceived at a time when security wasn’t what it is. It’s these damn kids that only know Python and JavaScript! Why can’t they be as smart as us C developers! This is all completely ignoring the fact that in 2023 we have no shortage of string manipulation-related vulnerabilities in widely popular and supposedly battle-tested C code. All some version of the typical list completely justifiable human err…

Full original
ZA
ZababaHN

I did start with C at university, C and Scheme. We didn't go very in depth in the "defensive programming" part, especially with C. We talked a bit about safety when we were doing web and database stuff, but I think that's it. I am pretty lucky, one of my friend is in cybersecurity, another is very good with C, and there are lots of people online freely sharing their knowledge, so at least I kind of know what I don't know. On the other hand, not everyone had that luck. I've seen a good number of people that are very good at what they do but lack more general culture. But it's hard to keep up with everything. Software is a huge world, I think already way too big for everyone to know everything. And it's not just software too, it's important to learn about business too, and maybe a bit of maths here and there isn't a bad idea, and there's also the hardware part, networking, and every day th…

Full original
Continue on Hacker News

Respect different perspectives. Share concrete experiences.

Sign in to post, reply, repost, and quote.