Community
Participate
Working Groups
See subj, parser won't do that. However, this is valid C++ syntax and C++ compiler has no problems with it: insigned var1(0); signed var2(0); // I figured this may also be a problem A good thing that these get parsed just fine: insigned var3=0; int var4(0); unsigned int var5(0);
Created attachment 111371 [details] proposed patch Function canHaveConstructorInitializer() does not take into account that "int" can be omitted when using certain specifiers. Allowing IASTSimpleDeclSpecifier.t_unspecified to have initializer seems to solve the problem. According IASTSimpleDeclSpecifier documentation t_unspecified is intended to be used exactly in such cases when "int" is omitted. Markus, is there another good reason for t_unspecified to make canHaveConstructorInitializer() return false? All test cases run by me (or rather those which made it through java heap) passed.
Markus, you worked on this part fairly recently like bug 84242, is there any chance you could take a look at this one?
(In reply to comment #1) > Markus, is there another good reason for t_unspecified to make > canHaveConstructorInitializer() return false? All test cases run by me (or > rather those which made it through java heap) passed. The situation is more difficult when you use an identifier as an argument: int varOrFunc(id); // variable declaration of function prototype? In the following situation, we know that we have a declaration for a ctor: varOrFunc(id); // this declares a constructor, not a variable. That explains why canHaveConstructorInitializer() checks for t_unspecified, however as you pointed out the check is not correct.
I see. In this case we could use additional check if modifiers are present with 4 functions: isSigned(), isUnsigned(), isShort(), isLong(). Let me redo the patch if you agree.
(In reply to comment #4) > I see. In this case we could use additional check if modifiers are present with > 4 functions: isSigned(), isUnsigned(), isShort(), isLong(). Let me redo the > patch if you agree. Yes, that's the way to go, you also need to check for IGPPASTSimpleDeclSpecifier.isLongLong(). I wait for you patch.
Created attachment 111540 [details] more fine grained patch Here is the patch. It is not necessary to check isLongLong() because isLong() will evaluate to true discovering at least one specifier "long".
(In reply to comment #6) > Here is the patch. It is not necessary to check isLongLong() because isLong() > will evaluate to true discovering at least one specifier "long". Not checking isLongLong() works only as long as you do not use the gnu-extensions (in this cast the long long is silently represented as long, which is questionable). I have modified the testcase and added the check for isLongLong(). Thanks for detecting the problem and looking into it! Fixed in 5.0.1 > 20080903.
Works as expected from head. Thanks for applying patch. I've been putting some effort trying to break it. Neither my attempts nor most prominent specimens from our code base showed any wrong. The best I could do was to crash eclipse with out of memory error.
