We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Anyone know why this syntax is highlighted incorrectly, or if there is a fix available?
See incorrect highlighting here: download2.efilive.com/.../syntax1.png
See correct syntax highlighting here: download2.efilive.com/.../syntax2.png
Regards Paul
Presumably, the highlighter is detecting the language as 'C', and is getting confused by the non-C part (the inline assembler).
So why don't you just use the __nop intrinsic, instead of messing about with inline assembler:
www.keil.com/.../armccref_cjabcdad.htm
Nothing non-C about the inline assembler in this case.
The highlighter should never try to understand the contents of #define statements. It should just concentrate on comments and continuation characters.
The highlighter should never try to understand the contents of #define statements.
"Never say never", as the saying goes. Sometimes it has to. #defines can contain all kinds of stuff --- sometimes there's so much code in there that you need syntax highlighting in there as much as you need it in normal code. And then there's the case of #defines containing unpaired parentheses that the highlighter has to keep track of to understand usage of those macros, e.g. the infamous C-for-Pascal-enthusiasts abominations
#define BEGIN { #define END }
But your example is an explicit example why the syntax highlighter should not try to understand the contents of preprocessor statements.
And people who are stupid enough to write BEGIN instead of a left brace really should not get any syntax highlighting of the rest of their code. A syntax highlighter that tries to solve the above problem will fail for people who write valid C/C++ code, just to possibly handle one or two abominations. I would consider that counterproductive.
If a user really wants to see syntax highlighting of preprocessed code, all real C/C++ compilers has an option to just preprocess the code.
I can't get the code to compile when using __nop - what is the correct syntax? Regards Paul
I don't think there is anything "non-C" in the #define. Well it is non-C, but it is not non-Keil-C, since the Keil documentation says to construct inline assembler that way.
It's no big deal, I'm just pointing out that there seems to be a problem with the syntax highlighter.
As a software developer, I appreciate my customers telling me when they find a problem (especially if they can also show how to reprodcue it) so it can be fixed, I'm just doing the same for Keil.
As a C programmer, currently developing in Pascal (Delphi), I would prefer to change BEGIN into { and END into }. I think the curly braces are far more elegant. I can't understand anyone wanting to go the other way. :)
Show the code that fails, and the message(s) produced...
"what is the correct syntax?"
Hopefully, the manual page reviously cited shows the correct syntax, doesn't it...?!
;-)
Paul; You do know that you are not communicating with Keil on this forum site.
I do note that Herr Keil does frequently answer on this forum but Keil support does not promise to monitor this forum. Any direct suggestion should be emailed to support@keil.com. However, your post did create several good points and info. I, for one, thank you for posting. Bradford