3 ms·

> All of these are very different from C. With the changes you have in mind, that new "C+" would be much closer to Zig than C. For a backward compatible bounds

> All of these are very different from C. With the changes you have in mind, that new "C+" would be much closer to Zig than C. For a backward compatible bounds-checking proposal see: https://discourse.llvm.org/t/rfc-enforcing-bounds-safety-in-c-fbounds-safety/70854 https://discourse.llvm.org/t/rfc-enforcing-bounds-safety-in-... This basically just associates a pointer and a length via new (and optional) annotations.

pjmlp 2y ago
That is what Microsoft is already doing since the Windows XP SP2 security task force, Apple came a bit late into the game. The void foo(int *__counted_by(N) ptr, size_t N); with SAL void foo(_In_reads_bytes_(N) int *ptr, size_t N); https://learn.microsoft.com/en-us/cpp/code-quality/understanding-sal?view=msvc-170 https://learn.microsoft.com/en-us/cpp/code-quality/understan... But given how much long time ago XP SP 2 was, and how many people actually use them, unless forced at their job, that is quite telling how much people care.
- Gibbon1 2y ago
  What bothers me is a function that takes both a ptr and a length is taking a phat pointer. What feels bad is you could add standard phat_ptr_t to the C library. But they refuse to do even that.
  - flohofwoe 2y ago
    Such a bounds-checking language extension needs to be able to annotate existing libraries without changing their API, otherwise it's not all that useful.
    - flohofwoe 2y ago
      PS (too late for edit so I'm replying to myself): with the above Clang extension you can also define your own phat_ptr_t struct and still associate the length with the pointer. Not sure if that's also possible with the Microsoft extension, for instance this is copied from the proposal text: typedef struct { int *__counted_by(count) buf; size_t count; } sized_buf_t;
    - Gibbon1 2y ago
      What I've noticed about C and it's problems with safety is the discussion always assumes that C will be replaced real soon now. So the problem is really about existing code bases. After 40 years of that I think that was a bad assumption. I also think that with annotations you can fix code mechanically. You got void foo(int *__counted_by(N) ptr, size_t N); That could be replaced mechanically by void foo(sized_buf_t buffer); And if it can't that's already a big problem.
      - flohofwoe 2y ago
        Yes, easy to do and a good idea in your own code but maybe not an option in a library that needs to remain API and ABI compatible with the previous version of the library that used separate ptr and size arguments (for whatever reasons - for instance Apple might want to harden system libraries without breaking existing applications).
- rurban 2y ago
  The proper simple syntax IMHO should better be something like: void foo(int ptr[n], size_t n); with ptr[n] not copying the full array, just that n is the size. you can try it now with: #include <stddef.h> #include <stdio.h> int ptr[6] = {0,1,2,3,4,5}; #define N sizeof(ptr)/sizeof(int) void foo(int ptr[n], size_t n) { // error: ‘n’ undeclared here (not in a function) for (unsigned i=0; i<n; i++) printf("%d ", ptr[i]); } void main(void) { foo(ptr, N); } instead of compile-time: #include <stddef.h> #include <stdio.h> int ptr[6] = {0,1,2,3,4,5}; #define N sizeof(ptr)/sizeof(int) void foo(int ptr[N], size_t n) { for (unsigned i=0; i<n; i++) printf("%d ", ptr[i]); } void main(void) { foo(ptr, N); } The Linux kernel [restrict .n] syntax is just too weird, almost perl-like, inventing new magic glyphs. And deviating from the normal restrict meaning.

pjmlp 2y ago

That is what Microsoft is already doing since the Windows XP SP2 security task force, Apple came a bit late into the game. The void foo(int *__counted_by(N) ptr, size_t N); with SAL void foo(_In_reads_bytes_(N) int *ptr, size_t N); https://learn.microsoft.com/en-us/cpp/code-quality/understanding-sal?view=msvc-170 https://learn.microsoft.com/en-us/cpp/code-quality/understan... But given how much long time ago XP SP 2 was, and how many people actually use them, unless forced at their job, that is quite telling how much people care.

Gibbon1 2y ago
What bothers me is a function that takes both a ptr and a length is taking a phat pointer. What feels bad is you could add standard phat_ptr_t to the C library. But they refuse to do even that.
- flohofwoe 2y ago
  Such a bounds-checking language extension needs to be able to annotate existing libraries without changing their API, otherwise it's not all that useful.
  - flohofwoe 2y ago
    PS (too late for edit so I'm replying to myself): with the above Clang extension you can also define your own phat_ptr_t struct and still associate the length with the pointer. Not sure if that's also possible with the Microsoft extension, for instance this is copied from the proposal text: typedef struct { int *__counted_by(count) buf; size_t count; } sized_buf_t;
  - Gibbon1 2y ago
    What I've noticed about C and it's problems with safety is the discussion always assumes that C will be replaced real soon now. So the problem is really about existing code bases. After 40 years of that I think that was a bad assumption. I also think that with annotations you can fix code mechanically. You got void foo(int *__counted_by(N) ptr, size_t N); That could be replaced mechanically by void foo(sized_buf_t buffer); And if it can't that's already a big problem.
    - flohofwoe 2y ago
      Yes, easy to do and a good idea in your own code but maybe not an option in a library that needs to remain API and ABI compatible with the previous version of the library that used separate ptr and size arguments (for whatever reasons - for instance Apple might want to harden system libraries without breaking existing applications).
rurban 2y ago
The proper simple syntax IMHO should better be something like: void foo(int ptr[n], size_t n); with ptr[n] not copying the full array, just that n is the size. you can try it now with: #include <stddef.h> #include <stdio.h> int ptr[6] = {0,1,2,3,4,5}; #define N sizeof(ptr)/sizeof(int) void foo(int ptr[n], size_t n) { // error: ‘n’ undeclared here (not in a function) for (unsigned i=0; i<n; i++) printf("%d ", ptr[i]); } void main(void) { foo(ptr, N); } instead of compile-time: #include <stddef.h> #include <stdio.h> int ptr[6] = {0,1,2,3,4,5}; #define N sizeof(ptr)/sizeof(int) void foo(int ptr[N], size_t n) { for (unsigned i=0; i<n; i++) printf("%d ", ptr[i]); } void main(void) { foo(ptr, N); } The Linux kernel [restrict .n] syntax is just too weird, almost perl-like, inventing new magic glyphs. And deviating from the normal restrict meaning.