Hacker News Reader

Comment by cmeacham98 | Hacker News Reader

What memory safe languages/tools existed in 1996 and still exist today with some meaningful marketshare? Java (barely, and I think it was proprietary at the time)?

It seems like "write memory safe C" was the best technique in 1996 if you wanted any semblance of portability/performance.

View on HN

I believe their (and this thread's) original point was that even absurdly widely used, studied, and continuously fuzzed C tools written and maintained by many serious experts for decades....

... still have multiple easily-uncovered memory issues.

Nobody writes safe C. Believing otherwise is delusional. This has been known for decades. But many believers still exist.

> Nobody writes safe C. Believing otherwise is delusional. This has been known for decades. But many believers still exist.

This is factually incorrect. You can write safe C code which is even correct according to some specification, as in "guaranteed bug free". This is not what most people do (or even know how to do) though.

I'm not aware of a generalized safe subset of C. There are lots of compiler extensions and model annotations that offer security improvements, but very few will claim to offer spatial and temporary memory safety in the way that safe programming languages can.

There are lots of specification driven C applications, which rely on (1) the specification being bug free, (2) the application of the specification being bug free, and (3) the model or proof assistant for the specification being sound and bug free. Getting all three of those is historically very difficult.

No realistic code that does that exists AFAIK. It may have sections that do it (which is great!), but not a total useful binary.

It's a straw-man that's trotted out every time, and it's utterly meaningless beyond academic arguments. Even if it is true, it's not relevant for any practical purposes.

In the FOSDEM presentation about Rust coreutils, they mentioned that security concerns were not a motivating factor for the rewrite - the C implementation has had only 17 CVEs since 2003.

https://fosdem.org/2023/schedule/event/rust_coreutils/

That's a very positive sign for the quality of coreutils, but does exactly nothing to assert there are no flaws.

And I'll point to CVE-2015-4041 as evidence in my favor - that's a buffer overflow: https://www.cvedetails.com/vulnerability-list/vendor_id-72/p...

I'm not sure what this has to do with my comment: my observation was only that memory corruption was a well understood vulnerability domain in 1996, not that there was a particularly wide variety of alternatives to C or C++.

Modula-2, Eiffel, Ada, Object Pascal,...

By 1996 people were building commercial web stores in Python. For example, see "The Real World Case Study: Python in a Commercial Environment" at https://legacy.python.org/workshops/1997-10/proceedings/stei... .

Don't forget about Perl!

I didn't want to get involved in what "meaningful marketshare" means with respect to Perl. In the same vein, AOLServer (ca. 1995) used multithreaded Tcl, and Tcl is also still around.

I remember that era, and Perl CGI scripts were everywhere. Tcl was pretty niche. I used it for some personal projects, but never ran into any web stuff that used it.

1995 is when CPAN started (the first "real" module repository, and the unambiguous best one for a very long time), and yeah - Perl was enormously popular then and especially shortly after for "it's not bash and it's not C" purposes. PHP was still new and WordPress didn't yet exist, and Perl was (and is) consistently beating it by a wide margin in performance.

For all the code-golf insanity that Perl supports, it's an extremely effective language with a truly stunning degree of both flexibility and performance.

Ada.

Common Lisp, depending on how you define memory safety.

If you remove the 'still exist today with meaningful market share', in '96 you had more options (e.g. Modula-2/2+/3 family).

There were others.

ISO Modula 2 has malloc/free-like routines, which you can easily misuse.

https://www.modula2.org/reference/isomodules/isomodule.php?m...

It also has pointer arithmetic, casting and sizeof in a SYSTEM module:

https://www.modula2.org/reference/isomodules/isomodule.php?m...

Which you don't have to use. Just like you can turn of Ada checks at compile time, leading to things like the Ariane-5 cockup. And Rust has 'unsafe', which as I understand allows you to do interesting things. So it's probably fair to say they all give you a footgun of some calibre, but you really have to want to take your foot off to use them.

All sorts of useful problem domains need dynamic allocation; you can hardly avoid using it at some point.

I'd actually like to see a Modula-2 example of, say, dynamically allocating an array object, which is dynamically sized. Because obviously Modula has better arrays which know their size, which a C program has to express all by itself with size fields and pointers.

I worked with Modula-2 quite a lot around 1990 but didn't do anything of the sort. I didn't know anything about any ISO standard or memory allocation functions provided thereby. A cursor search seems to indicate that it didn't exist until 1996; basically years after "peak Modula".

Lua originated in 1993 and ran anywhere C would.

Unfortunately it still lacks meaningful marketshare though.

I really like Lua but I've mostly needed it to write less maddening shell scripts, and it sadly falls flat when you need parallelism. And I mean an easy and intuitive one -- I know it has multithreading libraries but they produce overly complicated and verbose code.

Meanwhile you can just use `parallel` in your shell scripts with very little ceremony.

Lua is great in many ways but looking at it in 2023, it's kind of stuck in the past.

Reply on news.ycombinator.com