Permalink
Reply
On Wednesday, 22 June 2022 at 23:31:28 UTC, user1234 wrote:
>struct VLA {
private:
void* ptr;
size_t length;
public:
void setLength(size_t value);
}
struct Other {
VLA vla;
void imBad() {
vla.length += 1; // now I may have faults or not when reading the vla
}
}
This is a good starting point.
Yes, Other will be able to manipulate VLA's innard in this exemple. Now there are two questions that immediately come to mind:
1/ Should it be able to? From this limited example, it's hard to tell, but there is no need to be pedantic so we'll assume that yes it does. You'll note that this is not obvious per so, Other might be a view on the VLA for instance.
2/ If 1/ is true, then do they really belong in the same module?
I think 2/ is the question that is being skipped there, because the very characteristic of a module is to be the place where all the element it contains are implemented. If it is capital that Other is not exposed to the innard of VLA, then is it hard to defend that implementing them both together in the same place is the right design choice.
>It's about being strict with yourself. What if I'm not really good, make stupid mistakes ? Now I have a security barrier, I can use private(this), the compiler helps me with an error.
While I do indeed believe that it is good to be strict with yourself, I do not believe the arguments extends to private(this) based on the sample provided. In fact, I had to correct said sample to add an explicit reference to vla.length instead of just length. The compiler is already helping you avoiding accessing the innard of another object by mistake, it has to be explicit. The proof is in the pudding, the code had to be modified for it to be explicit.
