This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH]: Fix PR tree-optimization/21407
Mike Stump wrote:
On May 12, 2005, at 12:44 AM, Mark Mitchell wrote:
There simply is no resolution to this question in the standard.
There can't be an answer because the people who wrote the standard
didn't discuss these issues before writing it and didn't form a
I don't recall you in the room when we discussed the issue? Why do you
say this? I think we went to great length in the C++ standard to talk
about the model and to document it, and to given enough specificity in
the standard to allow others to know what we meant, and to know what we
thought the C standards group said and meant.
It's certainly not like I was around at a lot of the meetings way back
when, but I don't remember all these issues being resolved in
post-meeting mailings, or dicussions being relayed by committee reps I
talked to in their after-meeting reports. Until Nick's stuff, I'm not
sure anyone tried to write down a list of all the nasty cases.
I'm a little boggled, since it's my understanding that the C committee
hasn't yet worked out what it means, so I don't see how the C++ people
could have known what the C committee meant. And, if C's still actively
debating, and we presumably want to have C++ match C, then shouldn't we
consider any previous C++ decision somewhat in limbo until C resolves
things? I'd sure hate to have conflicting statements in C and C++.
In C++, have issues like what the effective type of memory is after
combinations of malloc/placement-new/explicit destructor calls been
fully resolved? So that we know exactly what pointer types are allowed
to access memory in these circumstances? Do we have resolutions in C++
to all of the issues raised in Nick's paper for C?
I think there's legitimate controversy. I guess nobody's happy with
that; the people championing one thing or another believe the standard
says what they want it to say. My position is that if this many smart
people disagree, there's legitimate controversy, and therefore we should