As soon as you forget (or your adversary manages to delete) an \0 at the end of any string, you may induce buffer overflows, get the application to leak secrets, and so on. Several standard library functions related to strings are prone to timing attacks, or have weird semantics that may expose you to attack. If you roll your own security-related functions (typical example: a scrubber for strings that hold secrets), you need to make sure these do not get optimised away by the compiler.
There's an awful lot of pitfalls and footguns in there.
I thought you meant a hello world or similar program only handling strings would be fundamentally insecure but rather you mean that it is hard to write secure code with C strings.
There are indeed a lot of pitfalls and footguns in C in general but I would argue that has more to do with c's memory focused design. I always feel like C strings are a bit of an afterthought but it does confirm well with the C design. Perhaps it is more so a syntax issue where the memory handling of strings is quite abstracted and not very clear to the programmer.
> I thought you meant a hello world or similar program only handling strings would be fundamentally insecure but rather you mean that it is hard to write secure code with C strings.
Disclaimer: I am not the author of the comment, and honestly I am more than happy if OpenBSD broke %n in printf because it looks awful from a security standpoint.
> you mean that it is hard to write secure code with C strings.
Indeed I do :) It is possible to write a "secure" hello world program in C; the point is that both the language and the standard library make it exceedingly easy to slip in attack vectors when you deal with strings in any serious capacity.
And on most Lumias, if your phone got scratched, lost its shine, or you just got tired of the color, you could just walk to the store and get a new "shell".
The other difference is that those 2 tons were the pinnacle of applied science at that time (heck in some way they are still pretty close to the _current_ pinnacle) and required the combined effort of hundreds of world-class scientists and engineers, unlike the 4000 tons of regular ordnance used in Dresden.
I am not that surprised, to be honest. Basically every C/C++ static analyzer out there does (among other things) some amount of additional "custom" type checking to catch operations that are legal up to the standard, but may cause issues at runtime. Of course in Python you have gradual typing which adds to the complexity, but truly well-formalised type systems are not that common in the industry.
Can someone give a strong rationale for a separate built-in class? Because "it prevents any unintended modifications" is a bit weak.
If you have fixed keys, a frozen dataclass will do. If you don't, you can always start with a normal dict d, then store tuple(sorted(d.items())) to have immutability and efficient lookups (binary search), then throw away d.
> variable names must not be longer than 6 characters
My memory might be lapsing here, but I don't think MISRA has such a rule.
C89/C90 states that _external_ identifiers only matter up to their first 6 characters [1], while MISRA specifies uniqueness up to the first 31 characters [2].
To make a more specific example, if you malloc()/free() within a loop, it's unlikely that the compiler will fix that for you. However, moving those calls outside of the loop (plus maybe add some realloc()s within, only if needed) is probably going to perform better.
That is something that can be easily found and usually fixed with trivial profiling. I'm more talking about data locality instead of pointer chasing. Once you set up a pointer-chasing data infrastructure changing that means rewriting most of your application.
I guess the crew has to stay pretty close to the end of the hose or it becomes hard to time the... flow... correctly. Likely, they still had to process the frames anyway to make the... flow... look like it comes out of Sterling's mouth, not from the side of his face, so it was basically no extra cost.
Not my kids, but I also passed my Networking course thanks to his guide (early 10s), and I used it as reference material for teaching about sockets in an Operating Systems course this year.
Used his book to learn networking in the late 10s! It's a timeless book at this point. Using the C/Unix socket APIs as the foundation is fantastic. He dives into code and actual network function so well for such a quick read.
There's an awful lot of pitfalls and footguns in there.
reply