No announcement yet.

Workshop 3 ver Compiler Bug

  • Filter
  • Time
  • Show
Clear All
new posts

  • jroman99

    Thanks for the clarification. I mistakenly thought that a delineated comment block had priority over the compiler trying to interpret things inside. Thankfully, the compiler's error message helps to narrow down the problem --once you understand what it's telling you.

    Leave a comment:

  • meldavia

    This is normal behaviour, whether it is classed as a 'bug' or not is debatable.

    Many compilers behave the same way in this respect.

    For the preprocessor to be able to ignore /* and */ inside a "string" constant,

    an opening quote (when found within a comment block) signals to the preprocessor

    'skip everything until closing quote found' .

    This of course has the undesirable side effect that you point out.

    If you find it neccesary to document exactly like what you have shown in your example,

    use the // style comment.

    Leave a comment:

  • 4DSysFan

    Those look like perfectly reasonable generated errors...... the */ is being interpreted as part of the string (since you don't have the closing quote mark), therefore the /* is unmatched......

    I'm not sure what else you would expect it to do?

    Leave a comment:

  • jroman99
    started a topic Workshop 3 ver Compiler Bug

    Workshop 3 ver Compiler Bug

    When using a "multi-line"-style comment i.e., /* ... */ , an unmatched double quote (") inside causes the compiler to give the following message (per my example):

    Error: string not terminated (line 7 file:abc.4dg)
    Fatal error: Found 1 unmatched comment block end '*/', starting on line 2 (line 7 file:abc.4dg)

    My code example with error on 2nd line:

    #platform "uLCD-28PT_GFX2"
    /* "abc */

    func main()

    Is this a compiler bug or "normal" C-like behavior?