3 ms·

https://spader.zone/sp/#null-terminated-strings-are-the-devils-work https://spader.zone/sp/#null-terminated-strings-are-the-devi... Pointer/length is not just

https://spader.zone/sp/#null-terminated-strings-are-the-devils-work https://spader.zone/sp/#null-terminated-strings-are-the-devi... Pointer/length is not just for strings - but for all arrays. See my proposal: https://www.digitalmars.com/articles/C-biggest-mistake.html https://www.digitalmars.com/articles/C-biggest-mistake.html

dboon 5mo ago
A comment from a legend. Thanks for reading and thanks for the response! I agree; the dynamic array is typed as a T* for ergonomics sake but is similarly a pointer and a length (and an allocator). Could I pick your brain a little more on the design? I'm spader at spader.zone; if you have time, drop me an email. I promise not to take too much of your time and I'd love to hear from you.
- WalterBright 5mo ago
  Thanks for the kind words! This can get you started: https://dlang.org/spec/arrays.html https://dlang.org/spec/arrays.html Strings (and arrays) being length/ptr is a freaking enormous win, in simplicity, performance, and overflow bug elimination. One of D's secret features is that string literals still have a 0 appended to them, even though the length of the string does not include the 0. This makes it super slick to call C functions, like printf, using a string literal for the format string. I'm baffled why C spends its energy doing things like normalized Unicode identifiers (an abomination) instead of something incredibly useful like length/ptr arrays.
x0re4x 5mo ago
I suggest using a slightly different array operator syntax for fat pointer arrays: "char a[|..|]" instead of just "char a[..]" to make them visually distinct and indicate that element access has additional bounds check. (syntax inspired by ocaml)
- WalterBright 5mo ago
  Thank you for the idea! I have no experience with Ocaml, so have no opinion on it. My experience is the simpler the syntax, the more people will use it.
secondcoming 5mo ago
But won't all those posix functions that take only `const char*` parameters need to be changed to be pointer/length?
- WalterBright 5mo ago
  No. For string literals, they already have a 0 appended, so no problem. For others, you'll need to malloc/copy/free. It hasn't been much of an issue with decades of D code.
gritzko 5mo ago
I use a C dialect with (ptr,ptr) slices and (ptr,ptr,ptr,ptr) buffers. Effectively a different programming language, still uses standard C compiler. https://github.com/gritzko/libabc https://github.com/gritzko/libabc In this day and age, the top problem is Claude bringing lots and lots of bad C into the code base. Takes a weekend to clear the week's mess. https://github.com/gritzko/beagle https://github.com/gritzko/beagle In a cleared codebase though all the usual C memory bugs are virtually non-existant. When did I see core dump last time? I do not remember. Thus feel no urge to use Zig or Rust.
- WalterBright 5mo ago
  Congrats! I had many years of chasing memory bugs. It certainly influenced the design of D a lot. Interestingly, I rarely make a memory bug these days. Too much experience, I've just learned not to make them. But I still prefer to use language features that make it easier to not make such errors.

dboon 5mo ago

A comment from a legend. Thanks for reading and thanks for the response! I agree; the dynamic array is typed as a T* for ergonomics sake but is similarly a pointer and a length (and an allocator). Could I pick your brain a little more on the design? I'm spader at spader.zone; if you have time, drop me an email. I promise not to take too much of your time and I'd love to hear from you.

WalterBright 5mo ago
Thanks for the kind words! This can get you started: https://dlang.org/spec/arrays.html https://dlang.org/spec/arrays.html Strings (and arrays) being length/ptr is a freaking enormous win, in simplicity, performance, and overflow bug elimination. One of D's secret features is that string literals still have a 0 appended to them, even though the length of the string does not include the 0. This makes it super slick to call C functions, like printf, using a string literal for the format string. I'm baffled why C spends its energy doing things like normalized Unicode identifiers (an abomination) instead of something incredibly useful like length/ptr arrays.

x0re4x 5mo ago

I suggest using a slightly different array operator syntax for fat pointer arrays: "char a[|..|]" instead of just "char a[..]" to make them visually distinct and indicate that element access has additional bounds check. (syntax inspired by ocaml)

WalterBright 5mo ago
Thank you for the idea! I have no experience with Ocaml, so have no opinion on it. My experience is the simpler the syntax, the more people will use it.

secondcoming 5mo ago

But won't all those posix functions that take only `const char*` parameters need to be changed to be pointer/length?

WalterBright 5mo ago
No. For string literals, they already have a 0 appended, so no problem. For others, you'll need to malloc/copy/free. It hasn't been much of an issue with decades of D code.

gritzko 5mo ago

I use a C dialect with (ptr,ptr) slices and (ptr,ptr,ptr,ptr) buffers. Effectively a different programming language, still uses standard C compiler. https://github.com/gritzko/libabc https://github.com/gritzko/libabc In this day and age, the top problem is Claude bringing lots and lots of bad C into the code base. Takes a weekend to clear the week's mess. https://github.com/gritzko/beagle https://github.com/gritzko/beagle In a cleared codebase though all the usual C memory bugs are virtually non-existant. When did I see core dump last time? I do not remember. Thus feel no urge to use Zig or Rust.

WalterBright 5mo ago
Congrats! I had many years of chasing memory bugs. It certainly influenced the design of D a lot. Interestingly, I rarely make a memory bug these days. Too much experience, I've just learned not to make them. But I still prefer to use language features that make it easier to not make such errors.