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>
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>
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>
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>
ARRAY_SIZE is a well known name pointing out that
we're dealing with array in macro argument.
Also to be on a safe side prefix_name helper should
check the index been in bounds more precisely.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
TOK_OTHER is legitime to follow TOK_PREPROC_ID so don't forget to handle it as well.
[ An addition to commit ec88c1beac ]
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
When we have switched to unified token pasting code we loose
backward compatibility. Restore it.
Note that new code MUST not expluatate this facility but rather
use paste macro %+ explicitly.
N.B. this patch is probably the candidate for revert, though
to give it a chance I commit it.
Reported-by: Alexey Dokuchaev
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
- no need to split functions even if it a bit longer
then 80 characters, it becomes hard to read it
- initialize "thead" before "tail" is more natural
- use more simple while() instead of for() with a
long initializer
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
We've a problem in supporting [i]rmacro, exitmacro
facilities at moment.
In a sake of not holding new NASM release any longer these
directives are just marked as being "forbidden".
This allow us to not squash much changes in current source
code base but remain on a safe side same time.
Reviewed-by: Keith Kanios <keith@kanios.net>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
It's really hard to read the code which is
terribly messed in tabs\spaces. Fix it all
at once. It's dirty work but has to be done
once.
No change on binary level.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
In case if EOF is reached (or due to any
other case pp_cleanup is being called) we
do free "defining" macro but forgot to set
pointer to NULL itself which leads to attempt
to free memory again for this macro on further
pp_cleanup calls.
If package can't be retrieved we should not attempt
to dereference NULL'ed pointer which leads to segmentation
fault.
Reported-by: Serge
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
The corner case is the code like
%define foo 1
%push bar
%$foo:
%pop
for which v2.07 ends up with "foo = 1" while 0.98.39
issue an error.
hpa said that ideally we may need to create a context
structure for the global context but this seems to be
too agressive for 2.08.
Based on patch from nasm64developer
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
