Michael Meskes wrote:
> > Michael Meskes wrote:
> > > The other option I can see, albeit without looking into details, is
> > > allowing all comments and then testing it for the right syntax after
> > > parsing. This could potentially also solve the above mentioned
> > > option problem.
> >
> >
> Michael Meskes wrote:
> > The other option I can see, albeit without looking into details, is
> > allowing all comments and then testing it for the right syntax
> > after
> > parsing. This could potentially also solve the above mentioned
> > option
> > problem.
>
> This idea sounds great. But I
Thank you for your kind advise!
Michael Meskes wrote:
> The other option I can see, albeit without looking into details, is
> allowing all comments and then testing it for the right syntax after
> parsing. This could potentially also solve the above mentioned option
> problem.
This idea sounds gre
> As I said in the first e-mail, there are some restrictions of comment
> position in my implementation. I am concerned that an error will
> occur in .pgc files users made in old version.
> So, this feature should be a new option.
I see, this makes sense.
> When the pre-compiler(ECPG) converts C
Hi,
Michael wrote:
> The reason for not keeping the comments in the statement was simply to
> make the parser simpler. If you added this feature, do we still see a
> reason for keeping the old version? Or in other words, shouldn't we
> make the "enable-parse-comment" version the default without a
Hi,
> So, I'd like to modify ecpg command not to remove some specific
> comments.
> ...
> [Interface]
> add a new option "--enable-parse-comment" to ecpg command.
>
> ecpg --enable-parse-comment ,..., prog.pgc
>
> This option enables ecpg command to pass on block comments (/* 〜 */)
> to c
