We could have accessed malloc'ed data on external symbols
in obj and ieee output formats. Fix it by using nasm_zalloc.
Reported-by: Jiri Malak
Patch-by: Jiri Malak
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
During nasm-2.06 development we broke the rules for
concatenation of preprocessor tokens (d784a083a3).
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 ec88c1beac , 20a94ad7fe and 984279b1dd 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>
read_input() shouldn't be part of the phash.ph module; instead it
should go into the sample usage file phash.pl.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.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 big numbers it's easier to estimate bytes count
if they are written in hex notation. Let it be so.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Handle immediate-size optimization for "mov r64,imm" -- reduce it to
"mov r32,imm32" or "mov r64,imm32" as appropriate.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>