5 ms·

I don't see how it mitigates anything. It merely adds a warning for _all_ older code and provides shiny new syntax exactly equivalent to an already popular prac

I don't see how it mitigates anything. It merely adds a warning for _all_ older code and provides shiny new syntax exactly equivalent to an already popular practice of passing array and its length next to each other. All array-out-of bounds errors that were happening before will happen with the new syntax as well, won't they?

woodruffw 3y ago
In theory, a new first-class slice type could only provide a “checked” interface, meaning that accesses through it would only succeed if in bounds. In practice, C doesn’t have great idioms for error handling, and so a proposal here would also probably need to explain how the slice type would either reuse existing idioms or introduce a new idiom (like Rust’s use of sum types). That makes the scope much larger, which in turn might explain any hesitancy from the C WGs to accept something like this (although I’m not actually aware of any).
- mjevans 3y ago
  Probably a warning flag that notes any non-compile time bounds checked references. Now that you mention it, some method of forcing bounds checks in more limited circumstances might be nice for performance, that or a cleaner method of expressly disabling such for areas with critical performance and where the input is considered trusted or already validated.
  - WalterBright 3y ago
    The array can be simply converted to a pointer to get unchecked access.
- WalterBright 3y ago
  Array bounds errors in D are treated as "go directly to jail, do not pass Go do not collect $200" errors. I.e. they are not recoverable, so no need for error handling. Many people have debated this and wanted such errors to be recoverable, but the principle in play is that the program is in an undefined state if there are such errors, and should not be allowed to continue as we wouldn't want it to launch nuclear missiles.
  - woodruffw 3y ago
    That’s (IMO) the right way to do it, but it’s also a harder pill to swallow from the C standards side: functions that die as a side effect rather than being UB are less precedented, have to be taught differently, etc. C’s lack of iterators also means that indexing bugs are more likely in idiomatic C programs than they are in equivalent C++ or D programs. This is another place where the standards body should improve things, but it also means that they’re somewhat constrained when it comes to slice proposals: making every index be potentially fatal is less palatable when your programming language doesn’t divert people away from indexing as much as it could.
    - CodesInChaos 3y ago
      Since dying is a valid implementation of UB, I don't see a problem. It's definitely better than memory corruption. In general my preferred way to handle OOB is an unchecked exception (like in Rust or C#), but that's not really an option C.
WalterBright 3y ago
It does not add a warning for older code. It does not affect existing code in any way. > Exactly equivalent to an already popular practice of passing array and its length next to each other. Differences: 1. passing pointer and length next to each other is a convention. This means the compiler doesn't know about it. 2. you cannot turn array bounds checking on and off with a compiler switch (though we strongly recommend leaving it always on) 3. your array bounds checking convention won't be compatible with someone else's code (standardization is a big deal) 4. I've never seen it used for strings. Strings are a major beneficiary of bounds checking 5. You have to document this every time you use it. 6. it's clutter 7. there's no check that the array/length variables are not mixed up or otherwise confused with other variables Most importantly, making a feature trivial to use makes for at least an order of magnitude increase in adoption of it. And what we want is adoption of it, right? The proof is that array buffer overflows remain the #1 problem with C bugs. P.S. I am always amazed at how C++ managed to get users to prefer: std::vector<int> a; over: int[] a;
- pjmlp 3y ago
  Because the 2nd is incompatible with copy-paste semantics from C code in C++. We can argue that C++ shouldn't have been that close to C, but that ship has sailed a long time ago.
  - WalterBright 3y ago
    My proposed new syntax can work with C++, too.

woodruffw 3y ago

In theory, a new first-class slice type could only provide a “checked” interface, meaning that accesses through it would only succeed if in bounds. In practice, C doesn’t have great idioms for error handling, and so a proposal here would also probably need to explain how the slice type would either reuse existing idioms or introduce a new idiom (like Rust’s use of sum types). That makes the scope much larger, which in turn might explain any hesitancy from the C WGs to accept something like this (although I’m not actually aware of any).

mjevans 3y ago
Probably a warning flag that notes any non-compile time bounds checked references. Now that you mention it, some method of forcing bounds checks in more limited circumstances might be nice for performance, that or a cleaner method of expressly disabling such for areas with critical performance and where the input is considered trusted or already validated.
- WalterBright 3y ago
  The array can be simply converted to a pointer to get unchecked access.
WalterBright 3y ago
Array bounds errors in D are treated as "go directly to jail, do not pass Go do not collect $200" errors. I.e. they are not recoverable, so no need for error handling. Many people have debated this and wanted such errors to be recoverable, but the principle in play is that the program is in an undefined state if there are such errors, and should not be allowed to continue as we wouldn't want it to launch nuclear missiles.
- woodruffw 3y ago
  That’s (IMO) the right way to do it, but it’s also a harder pill to swallow from the C standards side: functions that die as a side effect rather than being UB are less precedented, have to be taught differently, etc. C’s lack of iterators also means that indexing bugs are more likely in idiomatic C programs than they are in equivalent C++ or D programs. This is another place where the standards body should improve things, but it also means that they’re somewhat constrained when it comes to slice proposals: making every index be potentially fatal is less palatable when your programming language doesn’t divert people away from indexing as much as it could.
  - CodesInChaos 3y ago
    Since dying is a valid implementation of UB, I don't see a problem. It's definitely better than memory corruption. In general my preferred way to handle OOB is an unchecked exception (like in Rust or C#), but that's not really an option C.

WalterBright 3y ago

It does not add a warning for older code. It does not affect existing code in any way. > Exactly equivalent to an already popular practice of passing array and its length next to each other. Differences: 1. passing pointer and length next to each other is a convention. This means the compiler doesn't know about it. 2. you cannot turn array bounds checking on and off with a compiler switch (though we strongly recommend leaving it always on) 3. your array bounds checking convention won't be compatible with someone else's code (standardization is a big deal) 4. I've never seen it used for strings. Strings are a major beneficiary of bounds checking 5. You have to document this every time you use it. 6. it's clutter 7. there's no check that the array/length variables are not mixed up or otherwise confused with other variables Most importantly, making a feature trivial to use makes for at least an order of magnitude increase in adoption of it. And what we want is adoption of it, right? The proof is that array buffer overflows remain the #1 problem with C bugs. P.S. I am always amazed at how C++ managed to get users to prefer: std::vector<int> a; over: int[] a;

pjmlp 3y ago
Because the 2nd is incompatible with copy-paste semantics from C code in C++. We can argue that C++ shouldn't have been that close to C, but that ship has sailed a long time ago.
- WalterBright 3y ago
  My proposed new syntax can work with C++, too.