Re: Comments in %union processed incorrectly

[Paul Eggert]

> From: Akim Demaille <address@hidden>
> Date: 30 Dec 2001 11:14:31 +0100

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

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

> 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.

Sorry, I'm not a C++ expert.  I don't know what a "ctors" is.  What is
the relationship between ctors and yymemcpy?  For example, can one
safely use yymemcpy to copy the bytes of a Location class?  If not,
your code won't work anyway, even if it does compile.

If your code does safely work with yymemcpy, perhaps you could explain
the C++ issues to me, to help me propose a solution that doesn't cause
problems with C++.

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

> Date: Sun, 30 Dec 2001 12:17:39 +0100
> From: Hans Aberg <address@hidden>
>
> The second problem with unions and C++ is that the code uses:
> /* A type that is properly aligned for any stack member.  */
> union yyalloc
> {
>   short yyss;
>   YYSTYPE yyvs;
> # if YYLSP_NEEDED
>   YYLTYPE yyls;
> # endif
 > };
> 
> To me it looks as though the code constructs two or three stacks of the
> same value size using type (and I really do not know why the value type
> must be of the same size).

The code constructs two or three stacks.  Each has the same number of
elements, but the element sizes can all differ.  The union type is
used purely for size and alignment calculations; the actual stacks
typically have different numbers of bytes.

> However, I think of merging these different stacks into one. Then one would
> instead use:
> struct yyalloc
> {
>   short yyss;
>   YYSTYPE yyvs;
> # if YYLSP_NEEDED
>   YYLTYPE yyls;
> # endif
> };
> and use that type for a single stack.

That might make sense, though I would prefer not making this change
just before a release.  I suspect that it was done with separate
stacks originally for performance reasons.  Those reasons may no
longer apply these days, but I would measure any performance
degradation (if any) due to this change before installing it.