[Nasm-bugs] [Bug 3392358] NASM "forgets" macros and other defines.

[no-reply at bugzilla-nasm.gorcunov.org]

http://bugzilla.nasm.us/show_bug.cgi?id=3392358

--- Comment #6 from H. Peter Anvin <hpa at zytor.com> ---
So the issue is:

%if DPT_DRVDETECTINFO_SIZE_MULTIPLIER = 2

... is false in the first run of the preprocessor, but true in subsequent ones.

This causes the macro to get invoked on the subsequent passes, but not on the
first.  This happens because MAX_HARD_DISK_NAME_LENGTH is defined after struct
DRVDETECTINFO in Inc/BootInfo.asm; moving that EQU ahead of struc DRVDETECTINFO
makes the code build as expected.

This isn't an error in NASM *per se*, as this is probably impossible for NASM
to resolve, but it does put a finger on the fragility of NASM allowing symbols
to be accessed from the preprocessor.  This is, however, a design decision that
cannot be altered -- tons and tons of NASM code out there would break if that
was changed.

The real question is if there would be some way for NASM to detect when these
kinds of impossible situations crop up.  I could easily see situations, too,
where careless use of the preprocessor would cause NASM to loop forever trying
to optimize the code.  At the very least it would be good to generate an error
message that is unique to this situation.

One fundamental problem is that we don't treat the argument to RES* as a
critical expression, even though it almost certainly ought to be one.  The
question is if we can fix this without breaking a bunch of existing code; my
guess is that we can't.  We might be able to issue a warning if there is a
forward reference used in a RES* statement, however.

This wouldn't prevent errors caused by careless use of the preprocessor, but
those would at least be less subtle.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are watching all bug changes.