https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121068
--- Comment #11 from Jason Merrill <jason at gcc dot gnu.org> --- (In reply to Tomasz Kamiński from comment #9) > I remember that LWG3436 was discussed in core in Varna > (https://wiki.edg.com/bin/view/Wg21varna/CoreWorkingGroup#LWG3436) and the > current wording is result from there. Ah, right. > I was always suspicious about creating Tp[1] there, as in case when we are > creating a member (or any other object that is not transparently > replaceable), we will simply reuse storage and destroy the original object. > I do not think there is UB caused by lack of multidimensional array at that > location, but the new call is for sure not constant for the same reason. I guess the Tp[1] idea was justified by https://eel.is/c++draft/basic#compound-3 "an object of type T that is not an array element is considered to belong to an array with one element of type T" but that's qualified by "For purposes of pointer arithmetic and comparison", I don't see that it applies to the whole object model. My argument that this is UB is based on https://eel.is/c++draft/basic.lval#11 , thinking that int[3] is not accessible through int[3][1]. But that section also makes the point that access is based on scalars, so perhaps it doesn't apply. Actually, it's unclear to me what actually prevents us from creating a struct of one int overlaying an int.... > I agree that your proposed change seem to be much better direction, but as > far as I can see it does not match direction of > https://cplusplus.github.io/LWG/issue3436. Am I looking at wrong place? Ah, no, I was; https://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html seems to be out of date. I sent mail to the core reflector.
