Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The memory safety problem isn't bad coders

medium.com

Post reply on HN
Print view View original

101–110 of 225 posts

Re: The memory safety problem isn't bad coders

#101

Post by _bxg1 »

AdeptusAquinas wrote: post #86
_bxg1 wrote: post #69

Earlier quoted context omitted.

C/C++, and in many cases Lisp, seem to be the most entrenched communities when it comes to the "culture of seat-of-the-pants flying and bravado". For contrast, JavaScript has as much flexibility and nearly as many foot-guns as those languages, but its community has been much more receptive to safety rails and static analysis. (Hopefully this doesn't start a flame-war; that isn't my intention)

How. Dare. You. More seriously, JS has had its own resistance movements. TypeScript was actively disdained until, as far as I can tell, Angular switched to it. Probably partially because it was MS, but also because there was a lot of resistance to static typing despite the demonstrated safety benefits.

Yeah. My armchair analysis is that more flexible languages tend to attract smarter people, because they have a higher cap on how much your codebase can benefit from cleverness. Unfortunately those smarter people tend to over-estimate their own cleverness, and trying to take away someone's dynamic language features tends to be analogous to trying to take away Americans' guns.

Complex JavaScript codebases used to mostly be this way, but in recent years the JavaScript community has seen a huge influx of new, inexperienced programmers. There are obvious downsides to this, but one upside is that they don't have the pretense of being able to do everything perfectly without help, making them less resistant to things like TypeScript.

Re: The memory safety problem isn't bad coders

#102

Post by nickpsecurity »

pron wrote: post #91

Contrasting C and Rust completely misses the issue. Yes, obviously Rust will do away with some important classes of bugs and security vulnerabilities, but it's got nothing to do with addressing the problem. The problem is that there are billions of lines of C out there, and it will take many decades to replace them with software that's written in a memory-safe language. The issue is what do we do with all that existi…

There's a whole segment of CompSci dedicated to doing that. Softbound+CETS and SAFEbound are two of the better examples giving C memory safety. Data Flow Integrity is a newer one thst might be combined to bring security against data-oriented attacks.

The big issue with such tools is that C's lack of design and low-level nature make the tools have to be extra careful in ways that add extra overhead vs languages designed for verification (eg Gypsy, SPARK Ada). So, the slowdowns can be huge.

I still like them, though, given any approach that works turns the problem from "recode critical, legacy apps securely" to "buy a load balancer and some more servers." Huge improvement in feasibility.

Far as proving absence, RVI's RV-Match can do that against a full (or nearly so) semantics of C in K Framework. Their semantics, KCC, is mocked up like a GCC compiler to make it easy to try with code. It also gets stuck (fail-safe) on undefined behavior.

Re: The memory safety problem isn't bad coders

#103

Post by _hardwaregeek »

_bxg1 wrote: post #6

I remember when I first added ESLint to our large JavaScript codebase, and then again when I added Flow. I'm a perfectionist when I code, but it was shocking to see some of the things I'd written. Mistakes that I thought were so unlike me, but had been sitting there for months anyway, waiting to blow up. The human brain wasn't designed to handle the complexity of large codebases. There are just too many compounding i…

It's amazing how little we talk about tooling, both in work and in education.

I had an internship where I kept on trying to work on better tooling for the developers, only to be told that I should be working on the actual product because that's more important. Except, if I make the other developer's lives even 5-10 percent easier, then that will have a much longer effect than whatever work I can get done in 3 months. The most useful contribution I made in that internship was a document explaining all the features of the product with images, short videos and both the internal names and the client facing names.

And in school? Forget about it. Nobody shows kids how to use IDEs or editors properly. Nobody teaches git properly or command line tools. Nobody learns how to set up linters or heck, how to turn on -Wall -pedantic. Imo, every systems class should have a first lecture that explains Valgrind, proper compiler flags and Makefiles, and a last lecture that explains Rust. Realistically most students are not going to use Rust, but just understanding that it exists as a possibility can be useful.

Re: The memory safety problem isn't bad coders

#104

Post by gowld »

mhink wrote: post #76
wheelie_boy wrote: post #9

In general, in favor of as many correctness and other checks at compile time as possible. Make tools as powerful as possible. I really liked this tweet: "What if... - your programming language required you to write useful docs, - using those docs, it checked your program for mistakes, - it even used the docs to speed up your program, - this feature already exists! And what if it was called static typing." - https://t…

Although I mostly agree with you, it's worth noting that static typing only goes so far. When I worked in a large-scale Java codebase, it always seemed like half the code only existed in order to "work around" the type system. (Don't even get me started on Spring, which might as well be a whole additional language on TOP of the actual application code.) I'm perfectly willing to grant that might just be a Java thing,…

It seems strange to say that something (types) isn't worth anything more than nothing just because it isn't everything (complete documentation)

Re: The memory safety problem isn't bad coders

#105

Post by mort96 »

wheelie_boy wrote: post #9

In general, in favor of as many correctness and other checks at compile time as possible. Make tools as powerful as possible. I really liked this tweet: "What if... - your programming language required you to write useful docs, - using those docs, it checked your program for mistakes, - it even used the docs to speed up your program, - this feature already exists! And what if it was called static typing." - https://t…

Having used a bunch of libraries which seem to think that their source code with types (or auto-generated docs based on the types) is enough to be considered documentation... source code with types or auto-generated docs based on types isn't enough to be considered documentation.

Re: The memory safety problem isn't bad coders

#106

Post by applesvsoranges »

>> With a normal mutex we would be fine, since you only one lock can exist and it doesn’t matter if we unlock it on a thread other than the one we locked it from.

Sorry if this is a dumb question, but I'm confused. Aren't mutexes always supposed to have ownership which implies that only the locking thread can unlock them?

Re: The memory safety problem isn't bad coders

#107

Post by core-questions »

cm2187 wrote: post #92
AdeptusAquinas wrote: post #86

Earlier quoted context omitted.

How. Dare. You. More seriously, JS has had its own resistance movements. TypeScript was actively disdained until, as far as I can tell, Angular switched to it. Probably partially because it was MS, but also because there was a lot of resistance to static typing despite the demonstrated safety benefits.

Doesn’t static analysis requires static typing? There certainly has been a strong resistance to the introduction of static typing in the js community.

I'm not a very good developer, though I do have plenty of released-and-working-well things out in the world. I will say, it seems to me like static typing would reduce my creativity and flow and require me to spend more time planning stuff, which is not fun, and would make updates take more time as I patch stuff in all over the codebase. It's sort of the polar opposite of Ruby-style "duck typing".

Do they really help enough to be worth it?

Re: The memory safety problem isn't bad coders

#108

Post by pron »

nickpsecurity wrote: post #102
pron wrote: post #91

Contrasting C and Rust completely misses the issue. Yes, obviously Rust will do away with some important classes of bugs and security vulnerabilities, but it's got nothing to do with addressing the problem. The problem is that there are billions of lines of C out there, and it will take many decades to replace them with software that's written in a memory-safe language. The issue is what do we do with all that existi…

There's a whole segment of CompSci dedicated to doing that. Softbound+CETS and SAFEbound are two of the better examples giving C memory safety. Data Flow Integrity is a newer one thst might be combined to bring security against data-oriented attacks. The big issue with such tools is that C's lack of design and low-level nature make the tools have to be extra careful in ways that add extra overhead vs languages design…

Also https://trust-in-soft.com/

Re: The memory safety problem isn't bad coders

#109

Post by gowld »

jschwartzi wrote: post #67
maxxxxx wrote: post #56

Earlier quoted context omitted.

Not necessarily. The types may just have very long names. In C++ for iterating through STL container auto is a godsend. The types are very straightforward and easy to reason about but just long. for (auto it = s.begin(); it != s.end(); it++) { is much easier to write than for (vector ::iterator it = s.begin(); it!=s.end(); it++) {

I try to avoid using STL because it A) throws exceptions, B) has really convoluted type names, and C) dynamically allocates memory. These are all things you avoid in the embedded space.

Any use of templates has the same problem, including templates that are used to generate highly efficient static constants and non-branching-at-runtime code.

Re: The memory safety problem isn't bad coders

#110

Post by msla »

noir_lord wrote: post #30
risubramanian wrote: post #27

Earlier quoted context omitted.

The problem with that reasoning is that nearly every language with static typing also has some kind of type inference. You'll just wind up with a bunch of autos/vars.

Which isn't bad if the type inference is good . Nearly all the type errors I see are things like var foo = "Hello World"; bar = foo + 10; That should scream it's head off.

The kind of errors I'm interested in preventing are more like this:

    var foo = 5;

    var bar = 100;

    baz = foo + bar;
Why is that bad? Well... what do 5 and 100 mean in that program? Did you just add age in years to pixels from edge? How do you know?

Appending an integer to a string is comparatively sensible next to adding age in years to pixels from edge.

Post reply on HN