3 ms·

Many of the problems with C descend from a common root, the decision to use bare pointers (memory addresses) as the basic way to refer to strings, arrays etc.

Many of the problems with C descend from a common root, the decision to use bare pointers (memory addresses) as the basic way to refer to strings, arrays etc. If they had used a {pointer, size} pair instead, it would have avoided all of these string problems, most buffer overflows, even the GTA Online loading problem that was on HN recently.

Animats 6y ago
Pascal, which had sized strings, was in wide use before C. Many people, including Bill Atkinson, who wrote many of the original Macintosh applications, thought C was a step backwards. Pascal, to save one byte, limited strings to length 255. Bad decision.
- lelanthran 6y ago
  > Pascal, which had sized strings, was in wide use before C. Many people, including Bill Atkinson, who wrote many of the original Macintosh applications, thought C was a step backwards. Sure, but parent wasn't saying "it was not possible", they said "It was too expensive". And sure enough, the market drifted to the cheaper solution: you could run slightly more applications if your OS and applications were all written in C than if they were written in Pascal, Modula, etc.
cb321 6y ago
For what it's worth, while what @Camillo says is both true and important, people usually do not mention the trade offs involved or why that decision was attractive at the time. These days (ptr,size) is probably 16 bytes -- longer than almost all words in the English language (the scrabble SOWPODS maxes out at 15). A pointer alone is 8B. Back at the dawn of C in 1970, memory was 7..8 orders of magnitude more expensive than today..(about 1 cent per bit in 1970 USD). (Today, cache memory can be almost as precious, but I agree that the benefits of bounded buffers probably outweigh their costs.) 8B pointers today are considered memory-costly enough "in the large" that even with dozens of GiB machines common, Intel introduced an x32 mode to go back to 32-bit addressing aka 4B pointers. [1] There are obviously more pointers than just char* in most programs, but even so. Anyway, trade offs are just something people should bear in mind when opining on the "how it should be"s and "What kind of wacky drugs were the designers of language XYZ on?!!?". [1] https://stackoverflow.com/questions/9233306/32-bit-pointers-with-the-x86-64-isa-why-not https://stackoverflow.com/questions/9233306/32-bit-pointers-...
rightbyte 6y ago
If they would have used a "fat strings" for the standard lib there would have been at least four different types by now with 8 to 64 bit lengths. Maybe even with signed char as length field on some systems, unsigned char on other. Or signed and unsigned for all int:s for a total of 8 types. I think the sentinel character was the best choice in hindsight and at the time in that regard. But I wish the xxx_s versions and strdup would have made it into the standard like 30 years ago.
- spc476 6y ago
  There are no C standard functions, aside from malloc(), calloc() and realloc(), that have to allocate memory to work. I think that's intentional on the part of the C standard library.
  - rightbyte 6y ago
    strdup would be one in c22. Maybe they should have done a allocating "stradd" when they were at it ...

Animats 6y ago

Pascal, which had sized strings, was in wide use before C. Many people, including Bill Atkinson, who wrote many of the original Macintosh applications, thought C was a step backwards. Pascal, to save one byte, limited strings to length 255. Bad decision.

lelanthran 6y ago
> Pascal, which had sized strings, was in wide use before C. Many people, including Bill Atkinson, who wrote many of the original Macintosh applications, thought C was a step backwards. Sure, but parent wasn't saying "it was not possible", they said "It was too expensive". And sure enough, the market drifted to the cheaper solution: you could run slightly more applications if your OS and applications were all written in C than if they were written in Pascal, Modula, etc.

cb321 6y ago

For what it's worth, while what @Camillo says is both true and important, people usually do not mention the trade offs involved or why that decision was attractive at the time. These days (ptr,size) is probably 16 bytes -- longer than almost all words in the English language (the scrabble SOWPODS maxes out at 15). A pointer alone is 8B. Back at the dawn of C in 1970, memory was 7..8 orders of magnitude more expensive than today..(about 1 cent per bit in 1970 USD). (Today, cache memory can be almost as precious, but I agree that the benefits of bounded buffers probably outweigh their costs.) 8B pointers today are considered memory-costly enough "in the large" that even with dozens of GiB machines common, Intel introduced an x32 mode to go back to 32-bit addressing aka 4B pointers. [1] There are obviously more pointers than just char* in most programs, but even so. Anyway, trade offs are just something people should bear in mind when opining on the "how it should be"s and "What kind of wacky drugs were the designers of language XYZ on?!!?". [1] https://stackoverflow.com/questions/9233306/32-bit-pointers-with-the-x86-64-isa-why-not https://stackoverflow.com/questions/9233306/32-bit-pointers-...

rightbyte 6y ago

If they would have used a "fat strings" for the standard lib there would have been at least four different types by now with 8 to 64 bit lengths. Maybe even with signed char as length field on some systems, unsigned char on other. Or signed and unsigned for all int:s for a total of 8 types. I think the sentinel character was the best choice in hindsight and at the time in that regard. But I wish the xxx_s versions and strdup would have made it into the standard like 30 years ago.

spc476 6y ago
There are no C standard functions, aside from malloc(), calloc() and realloc(), that have to allocate memory to work. I think that's intentional on the part of the C standard library.
- rightbyte 6y ago
  strdup would be one in c22. Maybe they should have done a allocating "stradd" when they were at it ...