Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#743 C/C++ preprocessor syntax highlighting bug

Feature_Request
closed-invalid
Neil Hodgson
Scintilla (788)
2
2009-04-12
2008-11-18
Anonymous
No

Hi.

I want to report a bug with the C/C++ Source Code syntax highlighting.
In preprocessor directives, such as the #define macro, the C++ comments is included into the macro, i.e. it should not be treated as a comment.
For example:
#define URL "http://example.com/"
will give URL the value "http://example.com/", but the // will make Scintilla treat the rest of the line as a comment... it looks really weird.
The same is true for /* */ comments, in addition, the " in the end causes the rest of the line to go yellow:
#define LOGO "test /*test*/ test"

I encountered this bug in Notepad2, but the author told me this was a bug in Scintilla and told me to report it here.

Thanks, I hope you'll find the time to fix this bug.

Discussion

  • Kein-Hong Man
    Kein-Hong Man
    2008-11-19

    There *is* support for styling within preprocessor lines, in SciTE, you enable this by using the following:

    styling.within.preprocessor=1

    Guess Notepad2 needs a tweak. But, preprocessor styling *does* fail for certain corner cases, as the lexer does not process the text in the same way as a C/C++ preprocessor per what is stipulated in the ISO C standard.

     
  • Neil Hodgson
    Neil Hodgson
    2008-11-21

    Support for comments was added because people write things like
    #define FOO 6 // The state of FOO
    I wouldn't mind an option that turns this off and leaves the whole definition in yellow when styling.within.preprocessor=0.

     
  • Neil Hodgson
    Neil Hodgson
    2008-11-21

    • milestone: 100661 --> Feature_Request
    • priority: 5 --> 2
    • assigned_to: nobody --> nyamatongwe
    • status: open --> open-accepted
     
  • Kein-Hong Man
    Kein-Hong Man
    2008-11-21

    Some bits for interested implementors to consider:

    Lexing such preprocessor cases can work regardless of styling.within.preprocessor if the lowest lexing pass per ISO C standard is implemented. Among other things, this collapses comments into single whitespaces and recognizes basic token elements, including strings.

    Dunno if it's good or bad, or effects w.r.t. other languages using the C lexer, but it would take care of C corner cases such as:
    * whitespace and comments in preprocessor statements
    * multiline comments in preprocessor statements (seen as one preprocessor line)
    * "strings_with_*/" in /*block comments*/ should not end the comment block early

    Yet other C quirks that may or may not be worth doing:
    * non-standard ones like #pragma or #error are not in C syntax
    * sections totally blocked off using the preprocessor may not be legit C code

    The discussion in "The New C Standard" by Derek Jones covers most of this.

     
  • nyamatongwe: The comment in that case should styled, since the comment won't be included to the definition. In my case however, the comment is included to the definition inside a string, where it should not be styled.
    Consider this:
    #define URL "http://example.com/" //My website
    where 'http://example.com/' should not be styled, but '//My website' should be styled.

     
  • Kein-Hong Man
    Kein-Hong Man
    2008-11-24

    You should read the entire discussion very carefully.

    Your example is already lexed correctly in SciTE with the correct setting. If Notepad2 does it incorrectly, then you can tell the Notepad2 author to enable the option to lex inside preprocessor lines.

    On SciTE, some people perfer no lexing on preprocessor lines, some people prefer lexing. That's why there is an option to select this in SciTE. So, it's a Notepad2 problem.

     
  • Notepad2 was tweaked as suggested here in version 3.1.21-rc4, so this bug can be closed.
    Thanks for the help.

     
  • Neil Hodgson
    Neil Hodgson
    2009-04-12

    • status: open-accepted --> closed-invalid