Hacker Read

tyingq | karma 59102 | avg karma 3.47 · 2019-12-26 15:20:46

I wish C had gone back and done a better implementation of strings that wasn't null terminated. Or at least an implementation of plain buffers with a richer libc for manipulating them.

I know you can find bolt ons, but they aren't terribly useful since no 3rd party libraries use them. You have to resort to stuff like antirez's sds.

reply

Koshkin | karma 7543 | avg karma 1.41 · 2019-12-26 15:48:11+00:00

The choice is natural for C, due to the fact that it is the only way to implement the string simply as an array of characters. (Doing anything else would go against C's view of the world.)

tyingq | karma 59102 | avg karma 3.47 · 2019-12-26 16:14:41

I suppose, but watching everyone mess about with a struct that has length and a buffer, and a dearth of built-in functions to manipulate it, is...ugh.

tyingq | karma 59102 | avg karma 3.47 · 2019-12-26 18:44:59

An article with a better, and more dramatic explanation of the same opinion I have:

https://queue.acm.org/detail.cfm?id=2010365

reply

59nadir | karma 1408 | avg karma 2.1 · 2019-12-26 15:07:44

https://github.com/antirez/sds is heaps better than just using raw strings. Any language with a fat pointer variant out of the box is going to do it better than C as well.

That's not to say that the rest of C is bad, but there's nothing to be gained from defending C strings; they're bad and you should probably use an alternative and that alternative should probably have a length and a buffer, even better if you can find this out of the box in your language that otherwise works a lot like C.

reply

saagarjha | karma 56017 | avg karma 2.29 · 2019-12-26 16:54:48

I’m not sure I would call

  typedef struct {
      size_t size;
      char *buffer;
  } string_t;

“un-C”.

Koshkin | karma 7543 | avg karma 1.41 · 2019-12-26 18:31:30

Speaking of syntax, sure. Otherwise, this is as far from C as it gets. (Not saying that it’s not a useful representation, especially for substrings.)

klingonopera | karma 909 | avg karma 1.87 · 2019-12-26 22:18:57+00:00

C's "inherent inner workings" appear to rely on the fact that every char array has to be null-terminated.

That then implies at minimum a sanitation of user- and data-input of char array, and maybe an absolute maximum overrun char count protection at execution, but once your default is to keep track of every string length and not the opposite of keeping track of specific strings, I'd kinda agree with above that it's not really "C"... more like your own implementation of a(n overrun-safe) string library?

Inherent to the concept of the char array is that a size value would be redundant, for it is the position of the null-terminator that already contains/is this.

The analogy for the string concept of a char array's missing null-terminator is actually a wrong size value.

I ask myself, why are strings safer?

reply