For reals. The fact that C toolchains have never even offered a bullet-proof bounds-checked (no UB) mode, no matter what the slowdown, boggles the mind. For something like sudo, literally running 100x slower would not be an issue. Its highest priority should be security.
I have come to conclude that WG14 literally doesn't care about security, for them C should stay as a kind of portable macro assembler with amenities, and the same security guarantees as writing raw Assembly code.
Even the pseudo secure Annex K, requires separate arguments for actual length and max buffer length, thus defeating the purpose of being library functions for secure code.
Just having one of the many libraries that provide secure strings and vector handling, so that libraries can rely on a common vocabulary types would be an improvement.
Come on, wtf? Your computer can literally emulate another architecture in real time and you think sudo 100x slower would be humanly sensible? Computers literally wait eons for human inputs in the majority of times.
I assume you actually think that sudo takes the time it does, but you just likely entered your password wrong and are made to wait deliberately through a sleep. Are we really that bad at ball parking code execution times?!
I have once seen a proposal to make any sudo call wait for 10 seconds before doing anything so that the person running it has a moment to thing about what they just did do (and have ~10 seconds to ^C cancel it).
The person arguing also brought up that normally anything needing sudo should be automatized so that should be fine.
I'm not doing enough system administration to judge if that is a sane idea or not ;=)
That assumes that sudo the executable taking longer would linearly increase the time when in fact your OS loaded the exe into memory, created a process, allocated memory and let it go. A significant amount of time was just that, nothing related to the program’s job.