Handle C directives in source as any other code

[dolik-rce]

Problem

Consider this PEG code:

%header { #include "stdio.h" }

PackCC will fail to parse this, complaining about Premature EOF in code block. The reason is that it tries to parse the include directive, which consumes everything up to the newline, including the closing brace.

Solution

I propose to drop the special handling of C directives in source block. The only directive I can think of that would require this special handling would be a set of macros that builds a struct (or some other "scope") from simpler blocks, e.g.:

#define START_STRUCT_1(NAME) struct NAME {
#define START_STRUCT_2(NAME, SUFFIX) struct  NAME ## _ ## SUFFIX {
#define END_STRUCT }

This very synthetic example would result in unbalanced braces, but I think it would not be a very common occurrence. Definitely way more rare than including a single file and writing the directive on one line.

Possible alternatives

It could be also possible to check if the directive ends with closing brace followed by new line and stop parsing there. However it would probably be much more complicated and it still could break in some cases, such se with the END_STRUCT macro in the example above.

Another option would be to only parse #defines as directive and process #include, #pragma and other directives as regular code. This would allow one-line directives, while making the macros safe (and requiring them to always be in multi-line source blocks). This would probably work as well, but it makes things bit more complex unnecessarily .

[arithy]

I can understand what you want. However, I want PackCC to handle all valid C codes without exception. The specification you propose cannot provide programmers with any way to use elaborate macros as you gave an example, and might make them drop in a maze with puzzling problems. I think such macros are not so rare. The current specification would be simpler because it can declare just that all valid C codes are acceptable only if taking care of directives with braces as usual C codes. Moreover, I think it is not so inconvenient to have programmers do the following replacement. Wrong:

{ #include "stdio.h" }

Correct:

{
#include "stdio.h"
}

[dolik-rce]

I can understand what you want. However, I want PackCC to handle all valid C codes without exception.

In that case, the behavior must be mentioned in the documentation.

I have developed a PEG formatter (will be published soon), based on the PEG grammar description in README. And to my great surprise PackCC failed to process the formatted grammars, because directives with only one include have been shortened to single line.

Could we at least relax this behavior and process only #defines in this way? Other directives (#Include, #if, #pragma, ...) should be safe, I believe.

[arithy]

Sorry for my late response.

In that case, the behavior must be mentioned in the documentation.

I have added the description in README.txt (commit 0e3ee0c8b3f10909897927ce3b3febf49d6c65b2).

Could we at least relax this behavior and process only #defines in this way? Other directives (#Include, #if, #pragma, ...) should be safe, I believe.

I don't understand why you cannot accept a new-line at the end of a directive line. The C preprocessor catches all lines beginning with #, no matter which directive is specified. I want to esteem this C preprocessor specification.

There is a similar situation. PackCC can accept C++ style comments (//...). Braces in the comments also ignored appropriately like that in the preprocessor lines.

[dolik-rce]

I don't understand why you cannot accept a new-line at the end of a directive line.

Well, I can accept it and I will. It just seemed way too strict to me.

I guess it is because you look at the problem from the parser point of view, where it makes perfect sense that the behaviour regarding tu curly braces must be well defined. I was looking at it from the point of user, where I assumed %header { #include <stdio.h> } would behave just as if I included a file containing just that one line, without a newline at the end.

Anyway, I see that you can't be persuaded to change your opinion and your arguments are sound. So I close this PR and also the discussion, in order to not waste your time anymore.

Thank you for your patience and for the improvements in the documentation.

By the way: Here is the PEG formater I developed, where I bumped into this problem: https://github.com/dolik-rce/pegof