Hacker News Reader

Hacker News

Comment by WalterBright | Hacker News Reader

Full thread

WalterBright

D slices are fat pointers as well:

https://dlang.org/spec/arrays.html#dynamic-arrays

My suggestion for C to adopt fat pointers:

https://www.digitalmars.com/articles/b44.html

View on HN

> D slices are fat pointers as well:

So are Rust's.

Possibly more interestingly, so are its trait objects, the trait object pointer is a (vtable, instance) rather than (instance*, length).

Also of note: that applies to "owned pointers" (`Box`) not just "references", despite the former looking very struct-like: https://play.rust-lang.org/?version=stable&mode=debug&editio...

In a way, C++ and Rust (and possibly D?) have pretty much an infinity of fat pointers as anything can be made to deref' to something else, and be more than one pointer wide (e.g. C++'s std::string and std::vector and Rust's String and Vec)

  > Possibly more interestingly, so are its trait objects, the trait object pointer is a (vtable,
  > instance) rather than (instance*, length).

The Go interfaces are the same. See https://research.swtch.com/interfaces.

A chaotic part of me thinks that C should be illegal for security code for the lack of this.

Just Googled and seems fat pointers can at least prevent buffer overflow. I want to know more about other returns and costs on changing C to fat pointers.

https://security.stackexchange.com/questions/155572/how-are-...

They can prevent some buffer overflows, assuming that the data in the fat pointer remains correct. If you want to prevent buffer overflows completely you need to go well beyond that and effectively either use a higher-level language with a runtime and GC making sure everything remains coherent or do what Rust is doing with its borrow checker.

Not that I'm against fat pointers in C, I always thought that in hindsight not having a primitive "slice" type was a mistake. In particular using NUL-terminated strings instead of slices is both error-prone and makes implementing even basic string-splitting functions like strtok annoying or inefficient (you need to be able to mutate the source string to insert the NULs or you have to allocate memory and copy each component. If you had slices you could easily return a portion of the string without mutation or copy).

> If you had slices you could easily return a portion of the string without mutation or copy).

In this case you get another problem: how to free memory when there might be many slices pointing at it.

I mean, some types of implementation of fat pointers are fully compatible with the C spec, and would mean that undefined behavior will result in a crash rather than overflow. Slice behavior would not exist though.

How does

    extern void foo(char a[..]);

differ from

    extern void foo(size_t dim, char a[dim]);

if they are meant to be binary compatible?

The programmer doesn't have to keep both in sync manually, so there is less chance that they blow up, as it happens regularly in C code, even after being reviewed.

I don’t recall that syntax being valid C. I thought the length modifier had to be a literal.

It doesn't matter, because it gets ignored anyway.

Did people in the C community consider your proposal?

I haven't officially proposed it, but every time I've shown it to C people they're just silent - no response.

But anyway, you can use D in BetterC mode and have bounds checked slices!

https://dlang.org/spec/betterc.html

You might be interested in this paper: "CheriABI: enforcing valid pointer provenance and minimizing pointer privilege in the POSIX C run-time environment" https://blog.acolyer.org/2019/05/28/cheri-abi/

I would interpret the silence of C people as "Thanks, but no, thanks." The success of C for such long time without having fat pointers, exceptions, RAII, etc... is probably an indication they weren't needed that much.

(Jonathan Blow: Ideas about a new programming language for games.) https://www.youtube.com/watch?v=TH9VCN6UkyQ&list=PLmV5I2fxai...

C´s success is just like PHP and JavaScript successes.

When a language owns the platform its quality comes second.

Languages are maintained by people. When people have a monopoly quality comes second.

Whose interests are to push certain platforms.

Reply on news.ycombinator.com