As being pointed by "matching braces" topic on
[ http://forum.nasm.us/index.php?topic=905.0 ]
we don't issue warning on missed match for "{"
brace opened.
Strictly speaking we should issue error instead and
force user to fix asm source code but since it's
here for a long time already -- lets be "admissive".
Reported-by: Klod
CC: Frank Kotler <fbkotler@zytor.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
In mmacro params head TOK_NUM should be concat'ed with
tail TOK_NUM only, otherwise the weird construction like
%define id1 1
%define idid1 2
%define TOK_NUM 1
%define TOK_ID id
%macro m 2
mov eax, 1%1id%2 ; this expands to 1idid1
; where idid1 expands to 2
; and then to 12
%endmacro
m TOK_ID, TOK_NUM
issue error.
N.B. I've checked nasm-0.98.39 and it compiles this macro
perfectly well, for the record.
Reported-by: nasm64developer@users.sf.net
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
During nasm-2.06 development we broke the rules for
concatenation of preprocessor tokens (d784a083a3f1).
The former candidates for concatenation were (in terms of RE)
expand_smacro
[(TOK_ID|TOK_PREPROC_ID)][(TOK_ID|TOK_PREPROC_ID|TOK_NUMBER)]
expand_mmac_params
[(TOK_ID|TOK_NUMBER|TOK_FLOAT)][(TOK_ID|TOK_NUMBER|TOK_FLOAT|TOK_OTHER)]
[ nb: review commits ec88c1beac00 , 20a94ad7fe41 and 984279b1dde9 if
you going to change this one ]
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
If we're to print inside %rep block we should find
out which %macro it belongs.
Reported-by: Rob Neff
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
It seems to be a bit long story for the reason if this bug. But
lets be verbose and describe all byte-to-byte. And it is all about
preprocessor code, in particular paste_tokens and expand_mmac_params.
Initially the problem (not the same but similar) was noticed and
fixed in commit ec88c1be. The problem reveals itself with code snippets
like
| %macro m 1
| %push
| %define %$arg %1
| %%top_%$arg:
| resb ($ - %%top_%$arg)
| %pop
| %endmacro
So with commits ec88c1be, 51fd86e0, 1f6741fc, 985d880c we did expand
local single macro before processing tokens pasting unconditionally.
But then it being found that such approach breaks %assign directive.
The snippets like below didn't work
| %macro m 1
| %push
| %assign %$arg %1
| %assign %$arg %1+%$arg
| %pop
| %endmacro
So all these commits were reverted and we just stop pasting tokens
in paste_tokens() after TOK_PREPROC_ID (commit 20a94ad7). Unfortunately
this breaks %assign with compound preproc id
| %macro m3 1
| %push
| %assign %$_uses 0
| %rep 4
| %assign %$_ur%$_uses %$_uses
| mov ecx, %$_ur%$_uses
| %assign %$_uses %$_uses+1
| %endrep
| %pop
| %endmacro
To fix this bug we have to combine two approaches at once,
we should continue pasting after TOK_PREPROC_ID and expand
sequential TOK_PREPROC_IDs except first one.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
error() routine is conditional dependent so we should
use nasm_error instead to yield message unconditionally.
Reported-by: Christian Masloch
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Smacros are apparently stored with the token stream reversed, so make
sure %deftok matches that sense of relatity.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
error() routine is conditional dependent so we should
use nasm_error instead to yield message unconditionally.
Reported-by: Christian Masloch
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Make %substr robust to handle -1,-1 parameters
and restore old behavior when number of characters
in substring is greater then length of string itself.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Make %substr robust to handle -1,-1 parameters
and restore old behavior when number of characters
in substring is greater then length of string itself.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
In case if a second parameter of %deftok is missed we hit
NULL dereference. Fix it.
Reported-by: Christian Masloch
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
In case if a second parameter of %deftok is missed we hit
NULL dereference. Fix it.
Reported-by: Christian Masloch
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
For now we inform users about their sources need to be
updated and also since _all_ context case are legit
for single macros only we split lookup into two phases:
1) Lookup in active context, which is perfectly valid
2) Lookup in external contexts, which will be deprecated soon.
If (2) happens we yield warning.
A typical testcase is
---
%macro one 0
%push
%$a:
%assign %$b 12
%push
mov eax, %$a
mov eax, %$b ; hit -- context through
%pop
%pop
%endmacro
one
---
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Since %rep counter is a 64 bit signed integer we have to use some
"maximum possible value" limit (upper bound) otherwise there may be
a situation when %rep counter is 0 or even negative while user
has been passing big positive integer value.
Reported-by: nasm64developer
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Under particular circumstances %strlen may cause SIGSEG. A typical
example is %strlen with nonexistent macro argument.
[ Testcase test/strlen.asm ]
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Allow non-identifier characters in the name of environment variables,
by surrounding them with string quotes (subject to ordinary
string-quoting rules.)
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Add %ifenv to test for the presence of an environment variable. The
environment variable can, but does not have to be, prefixed with %!.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Revert to issuing a nonfatal error (it makes no sense to make it a
fatal error, but it probably makes sense for it to be an error instead
of a warning, especially since a lot of prior versions would crash and
apparently noone noticed.) We might have to revisit this based on
user requirements, and/or provide a method for the user to detect an
existing environment variable (%ifenv?).
Issue a better error message, indicating the nature of the failure.
Simplify the code by just updating the string in "p".
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Frank suggested to just print out an error if environment
variable is not there. Agreed.
Suggested-by: Frank Kotler <fbkotler@zytor.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Frank reported we hit NULL dereference on nonexistent
environment variables. Fix it by leaving empty string
in text field of such token and yielding warning.
Reported-by: Frank Kotler <fbkotler@zytor.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
At moment of calling the nasm_skip_string the string pointer
is already incremented which makes tokenize fail on correct
indirect strings.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
The commits
20a94ad7fe41c82f77fb670abb68f0de40d2b3e5
29c96651de1c43e59b7db58a4f06ff21dc854125
13dbfad76b4d3dbf27ef41761873584c6bd9fd7f
6f5f7ef417c37c154d10c2b3813808ad3fa65fd7
ddd08c3cccb4b68ecdb24d7a92eab6b2b82e8c68
seems to do the tricks we need. Eventually
get rid of commented "case".
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
In case if there is a whitespace before
'paste' token we may reach NULL dereference
in strlen since paste_head will point to
TOK_WHITESPACE. Fix it.
[test: paste.asm]
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
We need mac->nparam being explicictly int'fied otherwise
compiler issue a warning. Note that we might have been
using unsigned int but it would break an ability to pass
negative indices.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Peter proposed to expand local single macros unconditionally.
This should not hurt but give us more cleaner code in result.
Reported-by: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Peter proposed to expand local single macros unconditionally.
This should not hurt but give us more cleaner code in result.
Reported-by: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Introduce an ability to expand multi-line macros parameters in
a range/sequence manner.
For this purpose a special form is introduced %{x:y} which means to
expand %{x:y} to %{x},%{x+1},%{x+2},...,%{y}.
Both arguments could be negative or positive but MUST NOT be zero.
The arguments take into account possible %rotate as well.
Note that unlike the approach implemented in yasm we refer :-1 as
_last_ argument passed to a macro call, this makes possible to refer
the last element from macro via record as %{-1:-1} which could be
a convenient trick.
Also you can refer the argument in reverse order, ie it's legitime
to write %{5:4}, or even to reverse the all arguments %{-1:1}.
An example
|
| %macro mpar 1-*
| db %{1:-2}
| %endmacro
|
| mpar 1,2,3,4,5,6
in result we'll get the sequence of 1,2,3,4,5
Reported-by: nasm64developer <nasm64developer@users.sf.net>
Inspired-by: Mathieu Monnier <mathieu.monnier@polytechnique.org>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
