Re: BR 1582430: Allow numbers with leading + or - for %ifnum

> >>>> Allow numbers with a leading + or - to
return true for %ifnum.
> >>> This suffers from the problems described
in the SF request.
> >>>
> >>> For example, with your new behavior, how
does one handle
> >>> cases where the leading token _is_ meant
to be a unary op,
> >>> rather than a number with a leading sign?
> >> No difference, really.
> >
> > I don't follow.
> >
> > In case I wasn't making myself clear enough -- how
does one
> > get this new %IFNUM to reject e.g. "+
n", i.e. the sequence of
> > three tokens (unary add, whitespace, number), as a
number?
>
> What's your usage case?

A multi-line macro which did a quick %IFNUM test at
the beginning, and handed the arg off to more clever
processing if it wasn't a straightforward number (that
is, a single number token).

With your change, that %IFNUM now interprets "+
n"
as a number, but subsequent code then fails since it
is being presented with three tokens rather than just
a single number token.

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Nasm-devel mailing list
Nasm-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nasm-devel

anonymous coward wrote:
>>>>>> Allow numbers with a leading + or -
to return true for %ifnum.
>>>>> This suffers from the problems
described in the SF request.
>>>>>
>>>>> For example, with your new behavior,
how does one handle
>>>>> cases where the leading token _is_
meant to be a unary op,
>>>>> rather than a number with a leading
sign?
>>>> No difference, really.
>>> I don't follow.
>>>
>>> In case I wasn't making myself clear enough --
how does one
>>> get this new %IFNUM to reject e.g. "+
n", i.e. the sequence of
>>> three tokens (unary add, whitespace, number),
as a number?
>> What's your usage case?
> 
> A multi-line macro which did a quick %IFNUM test at
> the beginning, and handed the arg off to more clever
> processing if it wasn't a straightforward number (that
> is, a single number token).
> 
> With your change, that %IFNUM now interprets "+
n"
> as a number, but subsequent code then fails since it
> is being presented with three tokens rather than just
> a single number token.

Could you elucidate what that "subsequent code"
looks like?

	-hpa

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Nasm-devel mailing list
Nasm-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nasm-devel