This is a backport of commits
8dcbbd7af0d6d07b455de0b6460dca6db6113553
575d4289c9b1fb47774cb79764a24899a69a8d52
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
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>
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>
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>
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>
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 (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>
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>
