BUG: Killer comment!

[gammac]

Win32 version of NASM
NASM version 2.11.05 compiled on May 21 2014

Code: [Select]


; I'm a comment and I'm a killer bug \
label  nop
         nop
         jz label



Code: [Select]

error: symbol `label' undefined
A comment it's a comment it's a comment!!!


EDIT: I'ts allready known: http://bugzilla.nasm.us/show_bug.cgi?id=3392256

[Frank Kotler]

Sorry the line-continuation character doesn't work the way you (and Linuxero) think it should. It does what it does.

Now, %comment and %endcomment not working as documented - that's a bug. (maybe)

Best,
Frank

[gammac]

Normaly a single-line comment starts at their starting-delimeter and ends at the next newline character. Everything between starting-delimeter and newline character should be treated as ordinary character. That is what I'm thinking.

Something like this should not leading into an error:

Code: [Select]


; \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
; \ \
; \ \                            This it's my realy good new function. I'm so proud! ;)
; \ \
; \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
my_func: push ebp
...



[Frank Kotler]

Hmmm... the line-continuation character is documented (section 3.1), but is not listed in the contents or index (or I'm going blind - also true). That could perhaps be improved.

The problem, you see, is that Nasm needs to "get" a line before it could possibly preprocess or parse a line. That's where the line continuation character does its work. So Nasm has no way to determine if it's a comment or not. It continues the line, period.

You're not the first one to be bitten by this. I can understand:

Code: [Select]

5Bh ; [
5Ch ; \
5Dh ; ] <- gone bye-bye

What made you end the line with a backslash if you didn't intend it to be continued?

Best,
Frank

[gammac]

The problem, you see, is that Nasm needs to "get" a line before it could possibly preprocess or parse a line.

Yes, NASM simply should ignore everything after a ';' character and should start parsing again right behind the next newline character. Thats the normal behavior, I think only NASM looks what kind of character is the last character in an outcommented line.

Code: [Select]

5Bh ; [
5Ch ; \
5Dh ; ] <- gone bye-byeWhat made you end the line with a backslash if you didn't intend it to be continued?

EDIT: Your code snippet is a good exsample to show that NASM's behaviour it's very closed to a bug.

EDIT: I think NASM it's a bit lazy, if it's first doing is concatenating all lines that ends with a '\' - character. Or you could say, it's prioraty it's to high.