Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#540 EQU - %ifnum vs. %ifid

closed-invalid
nobody
5
2011-06-12
2011-06-11
p1ranha-rob
No

EQU can only be used to assign a constant numeric value.
However, when testing within macros %ifnum fails to recognize it as a number.

For example:

myval equ 1

%ifnum myval
%warning myval is a number
%elifid myval
%warning myval is an identifier
%endif

displays 'myval is an identifier.'

However:

%define myval 1

%ifnum myval
%warning myval is a number
%elifid myval
%warning myval is an identifier
%endif

displays '1 is a number'

The equated value also can not be coerced out:

%xdefine anotherval %[myval]

exhibits identical behavior to the above %if tests.

This makes it hard to prevent preprocessor errors when writing macro code that %assign's values to variables since an identifier may or may not be numeric and you can't be sure since the preprocessor is preventing access to the contents. Yes, I am aware that using %define rather than equ gives the proper test results but defines can subsequently be redefined. The constantness of equates is preferred in certain situations.

I'm not sure whether this is a bug, a feature request, or is simply behavior that can not (will not) be changed.

Tested with 2.09.08 and 2.10rc6

Discussion

  • H. Peter Anvin
    H. Peter Anvin
    2011-06-12

    It is simply behavior which won't be changed. An EQU is an identifier, just like a label. Furthermore, EQUs can be assigned to relative symbols as well as absolute constants.

    Since EQUs are not preprocessor constructs but assembler constructs, they are opaque to the preprocessor.

     
  • H. Peter Anvin
    H. Peter Anvin
    2011-06-12

    • status: open --> closed-invalid