321–330 of 340 posts
Earlier quoted context omitted.
That useful software would not have been less useful if the strings in it were represented as size + buf.
Oh really? Have you tried to rewrite anything to put your theory to the test? I don't think it's as straight forward as you think it is...
Earlier quoted context omitted.
> The code, but not the function, occurred in multiple places in the V6 kernel and userland. Yep. The code is essential given the design of the direct structure, which harkens back to the fixed-width data fields of punched cards.
It doesn't have anything to do with punch cards, it's to pack as many elements as possible into the very small amounts of memory on PDP-11s. A 16 byte directory structure (which divides evenly into a disk sector) with a 2 byte inode number and an up to 14 byte name is a memory-optimized structure, and memory optimization drove everything on UNIX. (I've been programming since 1965, used punch cards for a decade, was a…
Earlier quoted context omitted.
> non UTF-8 encoded strings on input/output I would just use UTF-8 everywhere.
Storing them as 32 bits wide in memory means you can at least index by a codepoint (if not a glyph).
Earlier quoted context omitted.
I did a project to translate data framed in the ASCII field/record separator characters and it was gloriously easy. All the ugly escaping considerations with comma-delimited data went away and it became much easier.
What happens when the data contains the record or field separator characters? I suppose you could document that it's unsupported, and just drop or reject such values, but then the system couldn't be used to handle test data for such systems, for example.
Earlier quoted context omitted.
LF makes the most sense, but they're all fine for text files. The issue is that CSV isn't text. Last time I had to handle CSV files in bash, I converted them internally to RS and FS.
Line feed resetting position really makes no sense. It should just continue text from where the cursor was but on next line. Like staircase. You need CR to go back to start.
CR is the only wrong choice. There's never a reason to go to start of line without erasing the line or moving to next line in a file. And even user interfaces will have smarter ways to do that. It's a completely useless concept outside of typewriters.
Well, CRLF (or worse, LFCR) is also obviously a wrong choice because it's pointless to demand two characters and create problems when one of them is missing when one totally unambiguous character will do.
Earlier quoted context omitted.
Clang and GCC both let you use Pascal strings in C if you would like (with `\p`). But Pascal strings aren't that useful today because the maximum length is too short.
Why would a pascal string be any shorter than a C string? A C string is one pointer reaching all of memory, a Pascal string is two pointers reaching all of memory
Earlier quoted context omitted.
> Typescript for C You mean "C with Classes", later to be replaced by "C++" (Stroustrup pick this as favorite from a list of candidate names he crowdsourced) as implemented by Cfront.
I preferred "P" because of the BCPL ancestor. If BCPL begat "B" and "B" begat "C", then "C" should have begatten "P". Not sure if begatten is a word :)
I have in the past made fun of the Linux kernel devs, supposedly some of the best C developers in the world, for not knowing how to make stringbuffer and stringview types, but to be fair to them we didn't have the consensus we have today on the topic. You know who did have the right idea though? Dennis Ritchie, who proposed a fat pointer type for C all the way back in 1990. Would have made for a perfect addition to C…
Earlier quoted context omitted.
I wasn't a programmer in these days, so I don't know if there's some other major concern that would kill this, but I sometimes wonder about whether we could have / should have used variable-length integers. That is, something like, 0-127 byte strings get their length prefixed, 128 - 16383 get two bytes of prefix, and the probably-rare 16384 - 2097151 strings would end up with three, though proportionally by that poin…
32-bit int isn't too much overhead. Just 3 additional bytes. I bet it's almost always better than c style strings. In the vast majority of situations the price isn't that bad, considering you make strings much more secure and potentially faster in string manipulations.
But remember the first Macintosh shipped with 128KB of RAM, 131,072 bytes. Three more bytes per string hurts a lot more there...
... although, that said, even in that era given the number of errors that null-terminated strings caused, even completely ignoring security, I do still wonder if at least defaulting to 2 bytes of length and doing something special for strings over 64K still wouldn't have been the right tradeoff, even in the case of short strings. Today we mostly focus on security, but null-terminated strings also caused a lot of just plain-old bugs. But so did 1-byte length strings... it's way too easy to run out of 256 characters even on those old systems.