@Conor Mc Bride in theory you can drive the length and breadth of the country in a car with no brakes, no airbags, no seatbelt, and a spike in the middle of the steering wheel and arrive perfectly safely. The car can still provide the essential function of getting from A to B, just as C can provide the essential function of implementing software algorithms.
And, in my case, no driving licence (or indeed, ability)! But driving is the right analogy, because people lie to themselves routinely about how well they do it. I miss the old (I have race memory) times when you had all day to regret last night's botched program run and really think hard about tonight's. I think that might be another driving analogue: the car is remarkably good at protecting the driver from their incompetence.
not a software person, but isn't lead piping easy to put in but bad for everyone using and touching it ever after, while software in C is devilish for the original programmer but quite fine once running?
The biggest problem with C is that pretty much nothing gets checked, and even that it’s not actually possible to check it. If you code perfectly and defend yourself against all possible rogue input, you MIGHT be OK. If something goes wrong, chances are it won’t even be caught until several billion CPU cycles later when the damage it’s done has crashed around in memory like an alpha particle in DNA.
It is common, for example, to write functions which handle multiple types of data. In C, since it doesn’t really have a type system to speak of, you pass the package and then tell it what sort of data you have passed.
It doesn’t check. It can’t check. The only validation that you’ve passed a Spong and not a Wibble is you saying, “this is a Spong, scout’s honour”.
So then you execute Spong handling code and, oops, you actually passed a Wibble, and it goes and corr
The biggest problem with C is that pretty much nothing gets checked, and even that it’s not actually possible to check it. If you code perfectly and defend yourself against all possible rogue input, you MIGHT be OK. If something goes wrong, chances are it won’t even be caught until several billion CPU cycles later when the damage it’s done has crashed around in memory like an alpha particle in DNA.
It is common, for example, to write functions which handle multiple types of data. In C, since it doesn’t really have a type system to speak of, you pass the package and then tell it what sort of data you have passed.
It doesn’t check. It can’t check. The only validation that you’ve passed a Spong and not a Wibble is you saying, “this is a Spong, scout’s honour”.
So then you execute Spong handling code and, oops, you actually passed a Wibble, and it goes and corrupts something.
But the something it corrupts isn’t even necessarily just the stuff you passed it. It essentially starts randomly firing a machine gun into the crowd. And the crowd is the rest of your program’s data.
If you’re lucky, it fires a bullet somewhere the operating system cares about enough to use the memory management unit to protect and the operating system immediately kills the process. If not, something randomly gets corrupted, and you find out … later by … some means.
Conor Mc Bride
in reply to Sarah Brown • • •So, yes, there's definitely a "we ought to know better by now thing".
But lead pipes are intrinsically contributing toxicity to the water supply by being made of lead.
C programs do not contribute toxicity to the program supply by being written in C. I think that's a noteworthy difference.
C programs contribute toxicity to the program supply by being written by C programmers. Your point stands.
Sarah Brown
in reply to Conor Mc Bride • •Conor Mc Bride
in reply to Sarah Brown • • •Sarah Brown likes this.
: j@fabrica:~/src; :t_blink:
in reply to Sarah Brown • • •Sarah Brown likes this.
: j@fabrica:~/src; :t_blink:
in reply to : j@fabrica:~/src; :t_blink: • • •Sylesej
in reply to Sarah Brown • • •Sarah Brown
in reply to Sylesej • •@Sylesej no. C is not fine once running.
The biggest problem with C is that pretty much nothing gets checked, and even that it’s not actually possible to check it. If you code perfectly and defend yourself against all possible rogue input, you MIGHT be OK. If something goes wrong, chances are it won’t even be caught until several billion CPU cycles later when the damage it’s done has crashed around in memory like an alpha particle in DNA.
It is common, for example, to write functions which handle multiple types of data. In C, since it doesn’t really have a type system to speak of, you pass the package and then tell it what sort of data you have passed.
It doesn’t check. It can’t check. The only validation that you’ve passed a Spong and not a Wibble is you saying, “this is a Spong, scout’s honour”.
So then you execute Spong handling code and, oops, you actually passed a Wibble, and it goes and corr
... show more@Sylesej no. C is not fine once running.
The biggest problem with C is that pretty much nothing gets checked, and even that it’s not actually possible to check it. If you code perfectly and defend yourself against all possible rogue input, you MIGHT be OK. If something goes wrong, chances are it won’t even be caught until several billion CPU cycles later when the damage it’s done has crashed around in memory like an alpha particle in DNA.
It is common, for example, to write functions which handle multiple types of data. In C, since it doesn’t really have a type system to speak of, you pass the package and then tell it what sort of data you have passed.
It doesn’t check. It can’t check. The only validation that you’ve passed a Spong and not a Wibble is you saying, “this is a Spong, scout’s honour”.
So then you execute Spong handling code and, oops, you actually passed a Wibble, and it goes and corrupts something.
But the something it corrupts isn’t even necessarily just the stuff you passed it. It essentially starts randomly firing a machine gun into the crowd. And the crowd is the rest of your program’s data.
If you’re lucky, it fires a bullet somewhere the operating system cares about enough to use the memory management unit to protect and the operating system immediately kills the process. If not, something randomly gets corrupted, and you find out … later by … some means.