6 ms·

I don't think it is a mistake in language design. In the 90s, memory was a rare good, and it still is in the microprocessor world, where "only" a few kilobytes

• bobbyi_settv 6y ago
  > There are performance critical paths where passing a size_t is just unnecessary You would still be able to declare your function as taking a pointer (instead of an array, which in this world would be a far pointer) if you need to He's saying to deprecate char[] as a parameter type, not char
  • WalterBright 6y ago
    That's right, nothing is taken away from the user with my proposal.
  • antiquark 6y ago
    An existing alternative is to put an array in a struct: struct string123 { char data[123]; }; Then create functions that user pointers to these string123 structs.
    • WalterBright 6y ago
      That does work, except for: 1. variable length buffers 2. every other piece of code you want to interface with uses `char*`
    • david2ndaccount 6y ago
      If you want a pointer to a fixed size array, just use one, eg char (*data)[123]; // syntax is somewhat awkward
      • mav3rick 6y ago
        You can type def that
  • tgb 6y ago
    Interestingly, I assume you meant to end your post with "pointer to char" not "char" itself, but asterix is the the italics formatting character on HN so it's italicized it. But the funny thing is that it's italicized the "reply" button (as well as an empty i-tag after "char").
• WalterBright 6y ago
  The #1 undetected bug problem with C programs is buffer overflows. Experience shows it is extremely difficult to verify that arbitrary C code doesn't have buffer overflows in it. Assistance from the core language design can improve things a great deal. D allows passing both raw pointers as parameters and pointer/length pairs. It's up to the user to choose. In practice, people have simply moved away from using raw pointers into buffers. As for performance, in C to determine the length of a string one uses strlen(). Over and over and over again on the same string. This can be a major performance problem, even not considering the memory cache effects. When I look at speeding up C code, often the first nuggets of gold is reviewing all the explicit and implicit uses of strlen(). (Implicit uses are functions like strcat()). It's also the first place I look for bugs when reviewing C code - anytime you see a sequence of strlen, strcat, strcpy, it's often broken (typically in neglecting somewhere to account for the extra 0 byte).
  • nmarks100 6y ago
    I don't agree that in the days of valgrind, asan etc. the #1 issue is buffer overflows. #1 and #2 are integer overflows and aliasing mistakes.
    • WalterBright 6y ago
      valgrind is a marvelous tool, but it only detects actual buffer overflows, not vulnerability to buffer overflows.
  • Gibbon1 6y ago
    All of this I agree with. In a better world 'arrays' would have added in the 1980's. The arguments about memory limitations is spurious since if you're writing good code you always pass a pointer and the length. Always no exceptions. Yeah and all the string functions should have been marked as depreciated with C89 and fully depreciated with C99.
    • mark-r 6y ago
      Yes, you can always pass a pointer and a length explicitly. And that's what the "safe" versions of e.g. string functions do. But it's still incumbent on you as the programmer to use them properly. It would still be beneficial to have a compiler mode where all that was done for you automatically and it was impossible to have a buffer overrun.
• mhh__ 6y ago
  You must pass a size_t somewhere, surely? Otherwise you have no idea how long the array is - this is about doing it properly rather than relying on yourself at 9AM to get it right everytime.
• mjevans 6y ago
  Then don't return or expect arrays. Return and expect Pointers of a given type. That's not going away in the article's proposal. It's being complimented by an array syntax that makes the current size (in memory) of a non-static data structure bounded upfront.