I don't think there are many bugs left in FASM, but here is one:



Works as expected, output is 11h 12h 13h 14h 15h



Works as expected, same output



Does not work as expected, invalid db,3h 12h,3h,3h is generated



Works as expected, output is 11h 12h 03h 14h 15h

El Tangas

Which is correct. Cause
define value 1#value
for the second macro argument is expanded into
define 2h,3h 1#2h,3h

This define in turn makes the second argument expand in db value, which is at first
db 2h,3h
, but after the define is applied becomes:
db ,3h 12h,3h,3h

Ah, ok thanks Because of the comma being special. Well, I kind of suspected there was no bug

However,

db,3h 12h,3h,3h

db ,3h 12h,3h,3h

are not the same string

Well, fortunately I figured out the correct way of doing what I wanted to do in the final macro (I think )

El Tangas

These are the same for fasm. There are two alternatives for fasm to tokenize statements: one is at least one tab/space between tokens and another one is a symbol character, which becomes a separate token. In both cases it doesn't matter how many more tabs/spaces you put in between, the statement remains the same for fasm.

E.g., a|b is the same as a | b, but a!b is not the same as a ! b.

There's also one special case of backslash, which is a "half-symbol character", i.e. it always starts a new token unless it's directly preceded by another backslash and it never ends a current token.

P.S. There's also one case of strings that need a separate little explanation, but you can look it up in the documentation.

Ok, I've never looked very deeply into fasm macro language, tokenization and preprocessing, but I was trying to write less trivial stuff, so guess I'll have to.