191–200 of 504 posts
what's wrong with OpenNTPD exactly?
One of them (lack of leap second support) is fresh on our minds since we just had a leap second. Some thoughts from the OpenNTPD folks are at http://undeadly.org/cgi?action=article&sid=20150628132834
Chrony is another alternate NTP implementation, here's their comparison vs ntpd and openntpd. https://chrony.tuxfamily.org/comparison.html
After reading this post the idea of a C-to-C translator that injects bound checking, etc. comes to mind. Such translator could be used by OS distributions to provide safety in the least intrusive way and possibly completely automatically for many C codebases they have in their repositories. Translating into Go or Rust, on the other hand, cannot scale beyond some individual projects, that decide to undertake such effo…
Realistically, the situation where you have source access with known errors you're somehow barred from fixing seems vanishingly rare.
Earlier quoted context omitted.
> i just don't understand why are buffer overflows such a huge problem in C when the same thing is going to come up when trying to work with memory in Rust. False. Buffer overflows in C can overwrite the program's memory, so it can be hijacked and supplanted with the attacker's code. This cannot happen in Rust (unless unsafe code has the vulnerability), or any memory safe language. Sure you can implement a safe array…
How much does that still happen with DEP and such? Don't OSes not let you write to executable regions or execute from stack/heap by default now?
Can anybody make a strong case to me as to why are buffer overflows considered an issue in C when it takes like 10 minutes to write and test an array implementation that prevents that from ever happening? I do agree that C has issues (though in my opinion neighter Rust nor Go address almost any of them) i just don't understand why are buffer overflows such a huge problem in C when the same thing is going to come up w…
Because: 1. Buffer overflows aren't considered the most insidious issue in C nowadays. That award would probably go to use after free, which is not so easy to fix. 2. In C, it is easier and faster to do the wrong thing. Compare "char buf[256]; strcpy(buf, foo); ..." to "array_t buf = array_create(strlen(foo) + 1); strcpy(buf.ptr, foo); ... array_destroy(buf);" 3. Buffer overflows do not in fact come up routinely in R…
Earlier quoted context omitted.
C is the new "goto". Y'all please, please note that dreta said "... an array implementation that prevents that from ever happening..."
Final word on the subject - what we have is people who are trying to make Open Software Reputation Points by finding a problem and fixing it, rather than waiting to find a real problem and fixing that. When the figure of "ten minutes" was used - that's really what it should be as a mean or median figure, with some long-tail outliers for knotty cases. While I am (somewhat) sympathetic, I don't miss what it is - it's m…
Earlier quoted context omitted.
No, Rust arrays are not safe by default: https://is.gd/iY5lPQ
Panics do not violate memory safety. In C that code would be undefined behavior.
Earlier quoted context omitted.
No, Rust arrays are not safe by default: https://is.gd/iY5lPQ
Panics are definitely safe. They are significantly different than the segfault you'd get out of the C code.
Earlier quoted context omitted.
Panics do not violate memory safety. In C that code would be undefined behavior.
You are right, my mistake. I just can't call code failing in runtime "safe" (because I can't rely on it). But in terms of memory safety it's safe.
Earlier quoted context omitted.
To be fair the [] syntax is an overridable operator and you could just point it to use the "at" method. Not sure why they've implemented it as an usafe function.
With C++, the default is zero overhead, not safety.
So if you are in a so performance critical section that you start to care about the "zero overhead" kind of stuff and the cost of your (predicted) bound checks, you might be impacted by this non-zero overhead... (that is falsely widely believed to be zero!)
And don't get me started about debug builds with all mainstream compilers. The performance is then complete utter shit. This is made worse by the fact such an unsafe language needs debug builds more...
C++ was an interesting experiment in its domain, and has been and still is a success in some aspects, but honestly given core language modifications are needed to significantly extend the behaviour of core types (like vectors, unique_ptr, strings, etc. -- e.g. with the introduction of rvalue references and all the associated machinery and default constructors and so over), I'm starting to believe there are little advantages of this approach over integrating such fundamental types/concepts in the core language (I'm not advocating to do that for C++, I'm thinking about other/future languages). Then you can have more true "zero overhead" stuffs, whatever that means.
I wish more mention of D would happen. It is compatible with C and C++ libraries and features GC without sacrificing the good things of C and C++. I always loved the idea of Rust and Go but they are nowhere near C or C++ where it matters to me. D fits the bill, otherwise I just use Python. I like being able to design software in my own way as opposed to being told how to do it.