41–50 of 93 posts
When I counted I got about 55% which is pretty close to the standard 2/3.
> So many people will now joke and say something about wide screens being available And this is a silly point because I want to be able to put 2-3 files side-by-side, on that big monitor. Who are all these people asking for long code that means I don't get more than one file on screen at a time?
It's not even just that. The reason newspapers have multiple columns rather than lengthy lines is because it's strictly easier to read shorter lines.
> We count about 40% of our security vulnerabilities to date to have been the direct result of us using C instead of a memory-safe language alternative. This is however a much lower number than the 60-70% that are commonly repeated, originating from a few big companies and projects. There has been discussion in an Arch Linux internal channel about the accuracy of these classifications. We noticed many advisories cont…
The guidelines feel out of sync with the directions I've seen people push coding styles over the years "Identifiers should be short" when I've mostly seen people decry how annoying it is to find yourself in a codebase where everything is abbreviated C-style (htons, strstr, printf, wchar_t, _wfopen, fgetws, wcslen) There's a case for more verbosity and if you look at modern Curl code it reflects that as well, new iden…
> Also related: (in particular local) identifiers and names should be short.
The general idea is that the more distant the identifier is, the more descriptive is should be. Because you don't have as much context, and it is also a hint: if you see a long, descriptive name, it is more likely to be global.
And descriptive doesn't mean long. You still need to try making your descriptive names as short as possible. For example "timeSinceMidnightInSeconds" can be shortened to "secondsSinceMidnight" without loss of information: seconds are a unit of time, no need to repeat it.
> We count about 40% of our security vulnerabilities to date to have been the direct result of us using C instead of a memory-safe language alternative. This is however a much lower number than the 60-70% that are commonly repeated, originating from a few big companies and projects. There has been discussion in an Arch Linux internal channel about the accuracy of these classifications. We noticed many advisories cont…
The problem is not as much C, but coding practices that make it seem like we're still in the 1970s. Codebases like curl use C at a very low level. But C has functions, has structures, has a lot of functionality to allow you to write at a higher level, instead of chasing pointers at each while statement. Code that handles pointers could be abstracted in the same way people will have to do in other languages.
The guidelines feel out of sync with the directions I've seen people push coding styles over the years "Identifiers should be short" when I've mostly seen people decry how annoying it is to find yourself in a codebase where everything is abbreviated C-style (htons, strstr, printf, wchar_t, _wfopen, fgetws, wcslen) There's a case for more verbosity and if you look at modern Curl code it reflects that as well, new iden…
When somebody says "short identifiers" in relation to C, this is exactly the style meant by that, not the cryptic style of C standard library.
> We count about 40% of our security vulnerabilities to date to have been the direct result of us using C instead of a memory-safe language alternative. This is however a much lower number than the 60-70% that are commonly repeated, originating from a few big companies and projects. There has been discussion in an Arch Linux internal channel about the accuracy of these classifications. We noticed many advisories cont…
For all it's many faults, even C++ fstreams is not vulnerable to double freeing (and as a partial reply to @Galanwe, they way they avoid issues is runtime checking).
It doesn't guarantee the issue never happens, like Rust would, but it does make it dramatically less likely to occur.
Also I think in general people vastly under-appreciate how severe an issue EBADF actually is. Outside of extremely specific, single-thread-only scenarios, that error is essentially the kernel telling you that heap corruption occurred, but almost nobody treats it with that level of severity
Earlier quoted context omitted.
It's not even just that. The reason newspapers have multiple columns rather than lengthy lines is because it's strictly easier to read shorter lines.
I don't think anyone disagrees with that, but 80 characters is clearly waaay too restrictive. I think 120 is much more reasonable.
> The question could possibly be exactly where to draw the limit, and that’s a debate for every project to have.
It is subjective, and does not live in a vacuum because along with purely subjective preference regarding it on its own, it affects, and is affected by, other choices like naming and indentation conventions.
They like 80 in their project. Feel free to choose something else for your project.
> We count about 40% of our security vulnerabilities to date to have been the direct result of us using C instead of a memory-safe language alternative. This is however a much lower number than the 60-70% that are commonly repeated, originating from a few big companies and projects. There has been discussion in an Arch Linux internal channel about the accuracy of these classifications. We noticed many advisories cont…
The question is: Could such bugs be avoided in C using the right tools and strategies. And the answer is also often: yes. This is why a large component of the argument for switching to other languages is usually that is impossible to avoid such bugs in C even for experts. But I think this argument, while having some small amount of truth to it, also is partially deceptive. One can not simply look at number of CVEs an…
In practice only when forced down MISRA like processes people seem to care, versus how relevant secure programming is seen in other programming language communities since 1960's.
Secure programming was part of Burroughs and Multics design, so why is the answer from a systems language community designed a decade later, and after 40+ years since the Morris worm, "we don't use right tools and strategies over here"?
"That's the neat thing -- you don't."
Curl should do what fish did: bite the bullet and rewrite the damn thing in Rust.