My Reaction to Dr. Stroustrup’s Recent Memory Safety Comments

Re:My Reaction to Dr. Stroustrup’s Recent Memory Safety Comm... by mbfg on Thursday February 02, 2023 @01:52PM (#34631353)

>> While there might be 30+ years of divergence between C and C++, none of C++’s so-called “progress” involved removing memory-unsafe C features from C++, many of which are still in common use, and many of which still make memory safety in C++ near intractible

I think just the concept of classes, and new, help with memory safety. It's harder to screw with memory with new Foo() then doing a malloc and memcpying bits into a buffer. Sure it's far cry from real memory safety, but i do think c++ has a bunch of improvements over c in memory safety. Sure you can do all the nasty bits in c++ that you could do in c, but you are carrotted out of doing them most of the time.

[ Parent | on HN ]

Re:My Reaction to Dr. Stroustrup’s Recent Memory Safety Comm... by olliej on Friday February 03, 2023 @12:06AM (#34637364)

Alas it doesn’t really help - new is just as bad as malloc, and the fact that there is no difference syntactically or in the type system between a pointer to an object and a pointer to an array means that c++s new introduces the joy of calling the wrong delete \o/

[ Parent | on HN ]

Re:My Reaction to Dr. Stroustrup’s Recent Memory Safety Comm... by david2ndaccount on Friday February 03, 2023 @01:54AM (#34637974)

This is incorrect, but most C and C++ programmers would be stumped by `int(*y)[3]` (which is how you spell a pointer to an array of length 3).

[ Parent | on HN ]

Re:My Reaction to Dr. Stroustrup’s Recent Memory Safety Comm... by pjmlp on Friday February 03, 2023 @02:50AM (#34638379)

Plenty of C++ developers still mix up delete versus delete[].

[ Parent | on HN ]

Re:My Reaction to Dr. Stroustrup’s Recent Memory Safety Comm... by olliej on Friday February 03, 2023 @03:18AM (#34638618)

Which is my point: the type system doesn't distinguish T* (a single object) T* (an array of objects), so delete vs delete[] only shows up as runtime heap corruption that may or may not eagerly terminate or lead to RCE.

[ Parent | on HN ]

Re:My Reaction to Dr. Stroustrup’s Recent Memory Safety Comm... by olliej on Friday February 03, 2023 @03:17AM (#34638611)

The type of `new T[N]` is T. The type of `new T[10]` is also T. The type of `new T` is also T.
Yes if you have a statically sized array you can make a pointer to an array of that length, but those are generally not relevant outside of specific cases (arrays in structs or on the stack where the size impacts offsets in codegen). More over the desire of C and C++ to drop those annotations is such that even using your proposal of a pointer to an array rather than just an array, is of questionable value. Take an extension of your example:
int(*y)[3] = ...; int(*y2)[3] = ...;
You can't do
*y2 = *y;
Because C doesn't let you assign arrays by value, even fixed size ones \o/

[ Parent | on HN ]