News for hackers. Stuff that matters.
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).
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[].
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.
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/