[raverbashing]

How about we start the retirement of C as it is a liability more than an asset at this day and age

How about we only use languages that (as you propose) work with memory slices not naked pointers and where the concept of a null pointer does not exist

How about we only operate on memory slices after checking boundaries

[microcolonel]

What? Are you going to force them? People write C because it is convenient, productive, and popular enough to attract contributors and find tools. C has the best dynamic analysis and debugging tools of really any language.

You can think yourself superiour and turn up your nose, but the fact remains that many people have perfectly good reasons to write and maintain C. Your haughty commentary has no impact on that.

You may think that bounds checking is the answer to all situations, but if you're writing a realtime system, there's often no point in running the program if it can fail from an out of bounds read or write anyway. In a flight control system, or an ECU, there is often nothing productive about crashing. You need to verify your pointer logic, instead of hoping your program will crash.

[raverbashing]

> You need to verify your pointer logic, instead of hoping your program will crash.

I love how most of the comments are, in essence "you're too dumb to use C". Just check the pointers right? Too bad people who think they are too smart do get bitten by those issues

I guess that's why people won't use other technologies beyond C in embedded systems (they do use)

[microcolonel]

You evidently didn't read and understand what you're responding to, try again.

[camgunz]

> How about we start the retirement of C as it is a liability more than an asset at this day and age

There's really only one replacement for C right now and it's Rust. If you don't like or can't use Rust (for whatever reason) you're gonna stick with C, and when you consider how much work has gone into making Rust a viable C alternative, it's clear we're a long way away from having a healthy ecosystem of C replacements.

[_ph_]

C (and C++, who inherited most problems with memory insecurity from C) are still used for a very wide variety of programs. There are plenty of alternatives to C other than Rust. Which of them is appropriate depends on the task at hand. In no particular order, all the following languages can replace C with greater memory safety:

Rust, Go, Oberon, Common Lisp, Scheme, D, Java

[camgunz]

Rust/D:

- Lack of library and platform support

- Lack of tooling

- Lack of standardization

Go:

- Lack of tooling

- Lack of standardization

- GC

- Slower

- Higher memory usage

Oberon (Ada, RTS, etc.):

- Lack of library and platform support

- Lack of tooling

- Lack of standardization

- Obscure

Common Lisp/Scheme:

- Lack of library and platform support

- Lack of tooling

- Lack of standardization

- GC

- Slower

- Higher memory usage

- Obscure

- Can't access arbitrary memory locations (?)

Java:

- GC

- Slower

- Higher memory usage

- Can't access arbitrary memory locations

I'm not really a C apologist, but I am pretty irritated with the near-constant calls for C deprecation. It's a lot easier to say, "C sucks!" than it is to do something about it, and I think we should at least internalize how difficult replacing C will be before we go around castigating people for continuing to use it.

[littlestymaar]

To be fair, C also has drawbacks

C:

- error prone

- Lack of modern typing (generics vs void pointer)

- Lack of dependency management

- no high level constructs

- unintuitive semantics (undefined behaviors)

[camgunz]

Oh absolutely! But those are merely drawbacks, not limitations. In contrast, there are many machines that simply can't host a JVM, or many platforms Rust just doesn't run on.

And that's just the "this is impossible" level. Sure you can build a database in Python, but it'll be slow and a memory hog, so if your requirements are "database, fast, low memory profile", then you can't use Python. Importantly, if you think those ever will be your requirements, you can't use Python.

I say this a lot but, engineering is about tradeoffs. There are still plenty of valid reasons to use C/C++. I'm tired of the knee-jerk "BOOOOO C" on HN these days, and while I certainly think we need to dispel the myth that you can write a meaningfully large, memory-safe program in C, I don't think we need to go as far as "you should never use C ever again". In fact, I think we need to be honest about the current state of the art in order to fully replace C -- which I wholeheartedly support.

[littlestymaar]

> In contrast, there are many machines that simply can't host a JVM

Well, if you're thinking in term of available resources, not really : most (if not every) chip on payment cards or SIM cards run Java[1] despite being incredibly limited in term of resources.

There are other (niche) example of Java running directly on bare metal, see Jazelle[2] for instance.

> or many platforms Rust just doesn't run on

Right now, absolutely but there is no technical limitation whatsoever that prevents Rust from running on these platforms. It might come, in the next decade or so if Rust gets enough traction, only time can tell.

I totally agree with the rest of your comment though.

[1]: https://en.wikipedia.org/wiki/Java_Card

[2]: https://en.wikipedia.org/wiki/Jazelle

[minipci1321]

> and where the concept of a null pointer does not exist

How that would benefit stability? I'd argue that having an equivalent of NaN for integer types would benefit array index computations more.

[raverbashing]

https://www.lucidchart.com/techblog/2015/08/31/the-worst-mis...

[microcolonel]

This is bloviatory though. NULL/0 is an incredibly useful value, it is the simplest to test for in hardware, which is why it is the basis of booleans in every major systems language. Because null is used for boolean evaluation, null is the perfect value for a pointer which doesn't point to anything.

Any time where you have an important distinction between the address of a valid object, and a non-address (next address at the end of a linked list, leaf node of a tree, failed initialization of a pointer). Zero is also used to terminate strings, for similar convenience/efficiency reasons.

C compilers and static analyzers together tend to catch possible null dereference bugs with near certainty these days, so people don't tend to ship them these days, if they make any effort at all. I have not encountered a null pointer dereference which wasn't typo-related in... I don't remember the last time it happened.

If you really want to be certain downstream users of your API won't struggle with it, put the null check in your sample code with a fat comment which says "This is NULL 0.001% of the time, and it really hurts when you don't handle that".

ALGOL, of course, is the sort of language which doesn't have pointer arithmetic. I would agree that a language without pointer arithmetic should not have NULL pointers, if only because it doesn't make any sense for there to be an abstract reference to an object which can not be used with functions designed for it.

In a language with integer pointers, like C, you check for null at allocation time. I've also seen people consider functions which could return NULL pointers to return something like an option type, where null is considered None, and everything else considered Some.

[littlestymaar]

Null is a useful value, but you don't need it everywhere, that's why many modern languages have opt-in null-able types instead of that as a default behavior.

I would argue than in at least 80% of the cases you don't want your values to be null, and that's in those situations mistakes are made (because you don't expect the value to be null !)

[raverbashing]

You seem to ignore all the failures and security breaches caused by null pointers and null terminators missing

[microcolonel]

No, I just think that in some cases it's worth it.

Some people should really be using bounds checks and option types more often, and I often use bounded functions for handling strings in fixed-size buffers. Some people write bugs into their programs for a lack of understanding or care given to these aspects of the language; but many people also make wonderful and unique things out of them.

I just don't think that the baby should be thrown out because somebody overfilled the bathwater. There is a time and a place for zero tests, null pointers, and pointer/index arithmetic.

[raverbashing]

> There is a time and a place for zero tests, null pointers, and pointer/index arithmetic.

Yes. In MMUless microprocessors with kbytes of memory or less