Re: too many warnings from Bison CVS for Pike

[Hans Aberg]

On 14 Feb 2006, at 08:02, Paul Eggert wrote:

> > when people compile your C-parser using a C++ compiler, they are
> > not compiling C-code actually,
>
> If they are not compiling C source code, then it's up to them to get
> things to work.  yacc.c is designed for C source code.

You are already writing C++ code by restricting to the common C/C++  
language subset (and using __cplusplus), apparently not giving  
thought to that this is actually C++ code -- but Akim has to check  
that this is legal C++ code. This is what he was saying: he checks  
that the code you write is also legal C++ code. Thus, users are not  
on their own, because Akim gives them support.

> It does not
> work well with C++ source code, and we shouldn't recommend it for
> that.

Because of those problems, I just tacitly assumed that the C compile  
as C++ feature had been retired. But Akim says he does support its  
presence.

Thus, I would not mind this feature would become retired completely,  
in favor of a genuine C++ skeleton only. This would be the right  
development move, but I cannot assess the legacy issue. In such a  
case, the C parser would have get added:

#ifdef __cplusplus
#error "Bison C-parser does not support compile by a C++ compiler."
#endif

Then you can use C-language constructs whatever.

> > but a C-like language subset of C++
> > that can be linked to proper C-code at need.
>
> If the user wants to use different C compilers for different parts of
> the application, it's up to them to get things to work.  This is true
> for random combinations of C compilers; it's also true for C++
> compilers masquerading as C compilers (which are just special cases of
> C compilers).  We shouldn't need to document all the issues here.
> They are generic issues, and are not specific to Bison.  Anybody who
> wants to mix C compilers should know what they're doing anyway; it's
> not the Bison documentation's job to educate them.

Right, I just wanted to explain the difference between the C code  
compiled using a C compiler and a C++ compiler. The C++ standard  
requires that one should be able to link to a C compiler, but it is  
up to the compiler manufacturer to make sure such a C compiler exists.

It is only a Bison issue in the part that it is possible to write a C- 
parser skeleton which does not compile at all under C++, but which  
still is usable to C++ users, as they still can link to it.

> I don't sense that we are making much progress here.  It would help if
> you would propose specific patches, in "diff -u" format.

I'll think about it.

> Otherwise I
> fear that we are just going around in circles.

You and Akim need to figure out what you want with the compile C as C+ 
+ option that now exists.
- Should it exist unaltered in its current form?
- Should be phased out completely in future Bison versions, in favor  
of a C++ skeleton?
- If it is retained, is it necessary, as now is possible, to be able  
to use C++ non-POD types, even though it results in a strange  
semantics (destructors not invoked immediately as expected)? If it is  
retained, and only POD types are needed (and required when using % 
union), then one can just as well use the dynamic C-parser already in  
place.

  Hans Aberg