3 ms·
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
by 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 agoSuch 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 agoPS (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 agoWhat 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 agoYes, 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).