Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fails to parse re-typedefs #9

Closed
cdisselkoen opened this issue Apr 7, 2021 · 2 comments · Fixed by #19
Closed

Fails to parse re-typedefs #9

cdisselkoen opened this issue Apr 7, 2021 · 2 comments · Fixed by #19

Comments

@cdisselkoen
Copy link
Contributor

FrontC fails to parse the following:

typedef int a;
typedef int b;
typedef b a;

even though this is accepted by clang.

Probably related is that FrontC fails to parse the following:

typedef int a;
typedef int a;

even though this is also accepted by clang.

@cdisselkoen
Copy link
Contributor Author

My guess is that FrontC sees the first typedef as typedef <type> <ident>, but the second as typedef <type> <type> which doesn't parse. Perhaps the solution is to add a case for <type> to typedef_dec

@ivg
Copy link
Member

ivg commented Apr 12, 2021

Sorry for the delayed reply, I was on a vacation. FrontC supports C89 and some pieces of C99. The declaration of typedefs was only allowed in C11 (section 6.7/3), therefore it is an expected and well-formed behavior.

The project was abandoned by its original authors so we adopted it to give it some retirement plan as there are still a few packages that depend on it. I would suggest switching to some other C frontend, instead of relying on FrontC in new projects as we don't have any intentions to update this project and add new features.

We would, in general, accept pull requests with the new features but the project doesn't have any testing infrastructure and it is hard to assess the impact of the change in the grammar on its correctness, especially with respect to the type definitions. FrontC uses an ugly approach of maintaining a hashtable of names so that the grammar itself is hiddenly changed when a new typedef is introduced. Therefore allowing redefinitions of type might introduce a nasty interplay between the state of the parser and the hidden state that holds typedefs. Or might not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants