Re: Comments in %union processed incorrectly

[Akim Demaille]

>>>>> "Paul" == Paul Eggert <address@hidden> writes:

>> The problem is that we now use an union to compute the alignments,
>> and only for that.

Paul> The union is there for more than just computing alignments.  It
Paul> is also for avoiding warnings when casting pointers.  I suppose
Paul> we could cast through void * first; I originally considered
Paul> doing it that way, but rejected it because void * is error-prone
Paul> and also I worried that casting through void * would inhibit
Paul> some optimizations.  I didn't know about the C++ problems,
Paul> though.

OK, thanks for the explanations.

>> It just happens that I do have a Location class, which does have
>> ctors.  But now, because of this single union, this is no longer
>> proper C++: classes with ctors cannot be stored in a union.

Paul> Sorry, I'm not a C++ expert.  I don't know what a "ctors" is.

Common abbreviation for constructors, sorry.

Paul> What is the relationship between ctors and yymemcpy?  

I was not referring to memcpy at all, just to union: thou shalt not
put objects of classes with constructors in unions.  And I use a
class Location.

But forget about it, I'll use the other branch, sorry for the noise
Paul.



Paul> Here's an idea: we could avoid yymemcpy entirely, and simply use
Paul> for-loops that copy the stack elements one by one.  We could use
Paul> __builtin_memcpy if using GNU C (not GNU C++), for performance
Paul> reasons on GNU C hosts; but otherwise we could just use the
Paul> for-loops.  Perhaps this would avoid the problem with C++
Paul> constructors that Hans Aberg mentioned.

No, really, forget about it: C and C++ are different, and any attempt
to have the two of them in a single skeleton is wrong.


Paul> That might make sense, though I would prefer not making this
Paul> change just before a release.  

I definitely agree.

Paul> I suspect that it was done with separate stacks originally for
Paul> performance reasons.  

Yes, that was my understanding too.

Paul> Those reasons may no longer apply these days, but I would
Paul> measure any performance degradation (if any) due to this change
Paul> before installing it.

I had come to the same feelings.



But we don't have even have enough time to flush our todo list: some
people keep stacking even more stuff.  This is just internal details,
there is more urgent elsewhere.