Menu

Optionally parsing a userAttribute "USER_ATTRIBUTE" in declaration and Optionally parsing type_qualifier and type specifier before cast expression in assignment_expression

2023-11-20
2023-11-20
  • Hariharan Mari

    Hariharan Mari - 2023-11-20
    1. Previously the Moritz tool could not parse when we have user specific attribute in the declaration eg. static int array[10] USER_ATTRIBUTE; (Here USER_ATTRIBUTE is a Macro) will now be able to parse.
    2. Similary in code MACRO(const int variable = 0); type_qualifier and type specifier before cast expression in the assignment_expression is not parsed before and now it can be parsed.

    Please let me know if this change can be accepted for the tool or if you suggest a better way to parse the c code for me. I attach the C_only_grammer file for ur reference.

     
  • Eckard Klotz

    Eckard Klotz - 2023-11-20

    Hello Hariharan Mari.

    Sorry but I'm not satisfied by your modification.

    1. You have not provided source examples which demonstrate your issue and which could be added to the "UserExample.c" source for testing purpose in the future when other changes will be implemented.
    2. It seams to be based on the latest release grammar but not on the latest patch . Thus we would lose all bug-fixes done since the release.
    3. Your syntax rule is using string - constants which seem to be very user specific. This is not a generic approach that may solve a similar issue.

      userAttribute = ("USER_ATTRIBUTE")
      | ("__" >> "ATTRIBUTE_PREPROCESSOR");

    4. First of all provide an example source to demonstrate your issue. At the end this snippet is used for demonstrating, that your issue is solved and for testing-purpose in the future.

    5. Second please use the latest patched grammar as base for your modification. May be it is already solving your issue.
    6. Third only generic solutions could be added to the generic grammar. Are your sure that the identifiers USER_ATTRIBUTE and __ATTRIBUTE_PREPROCESSOR are defined by the C or CPP standard? Or are this identifiers defined by your self?

    In the case that you have defined this identifiers by your self and your solution is a workaround to deal with the fact that the use of your preprocessor definitions results in breaking the c/cpp syntax without using a preprocessor, I would suggest to put all rules added or modified by you in an own grammar file "modification_c_only.a2x".

    In the file abc2xml_Process_ansi_c_only.xml you you will find the following lines:

    <file value="./LangPack/ansi_c/a2x/ANSI_C_Source_C_only_grm.a2x" root="LangPackPath">
    <file value="./LangPack/ansi_c/a2x/ANSI_C_Source_C_Pragma_grm.a2x" root="LangPackPath"></file></file>

    Add behind the line, that defines the use of ANSI_C_Source_C_only_grm.a2x, a similar line, that defines the use of your own grammar file "modification_c_only.a2x":

    <file value="./LangPack/ansi_c/a2x/ANSI_C_Source_C_only_grm.a2x" root="LangPackPath">
    <file value="./LangPack/ansi_c/a2x/modification_c_only.a2x" root="LangPackPath">
    <file value="./LangPack/ansi_c/a2x/ANSI_C_Source_C_Pragma_grm.a2x" root="LangPackPath"></file></file></file>

    This way your own grammar will be able to redefine rules already defined by original grammar and your new rules will be added also.

    Best regards,
    Eckard Klotz.

     

    Last edit: Eckard Klotz 2023-11-20

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.