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 ec88c1beac00 ]
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>
The first argument passed on stack with "flat64" stack model
(stack frame with base pointer) should be pointed by
[rbp + 16].
Signed-off-by: Per Jessen <per@computer.org>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Frank reported:
|
| From the "expert questions" forum comes this:
|
| ---------------------
| By: jasper_neumann
|
| How can I delegate %undef?
|
| In the example below the assembler (called with "nasm.exe -t -f rdf q.asm")
| bemoans my code, displays
|
| "q.asm:19: error: interminable macro recursion"
|
| and hangs.
|
| q.asm
| -----
| bits 32
| CPU P4
|
| %macro my_def 2
| %xdefine %1 esp+%2
| %endmacro
|
| %macro my_undef 1
| %undef %1
| %endmacro
|
| global check_it
| check_it:
| my_def x,4
| mov eax,[x]
| my_undef x
|
| my_def x,8
| add eax,[x]
| my_undef x
| ret
|
So in case of interminable macro recursion we should break
the expansion procedure that way to not return back and start
expand macro again.
This address a part of the original problem.
Nasm64developer pointed out:
|
| Btw, after you manage to fix this recursion problem, the code
| in question still faces the same fundamental issue -- the arg
| to the my_undef invocations (i.e. x) gets expanded first; thus
| the %undef inside the macro sees esp+4 and esp+8 instead
| of x, and fails. What you'd need is a means to prevent the ex-
| pansion -- look for e.g. %# in 4.1.4 of the manual.txt which is
| attached to SF #1842438; it implements exactly that -- I once
| filed SF #829879 for this feature.
|
In turn Keith Kanios said:
|
| Anon is also correct in that we would need a special directive to instruct
| the delay of macro expansion, although I don't see this as critical or even
| high priority at the moment. The intermediate solution for this is, don't
| use indirection if it is not needed... an inline %undef should be
| sufficient.
|
Reported-by: Frank Kotler <fbkotler@zytor.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Reviewed-by: Keith Kanios <keith@kanios.net>
We only ever invoked the preprocessor with fixed values for efunc and
evalfunc, so call nasm_error() and evaluate() directly.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Strings returned by nasm_unquote() can contain NUL characters, which
will not be legal if then used as a C string. Create a general
function which looks for NUL characters in the string and issues an
error if they are found.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
When the user generates an error via %warning, %error, or %fatal,
treat is as any other error message. The attempt at making them stand
out really looked ugly when the preprocessor adds additional tracing
information.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
We always need to process %+ at least once, but we also always need to
reprocess smacros after pasting. The solution to this is to make sure
we always reprocess %+ after the first expansion pass.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Revert to the earlier behavior of not expanding %+ until the final
phase of smacro expansion. However, the previous code has:
if (expanded && paste_tokens(&thead, true)) {
... which would inhibit paste_tokens() if expanded was false on the
first iteration. However, if expand_mmac_params is not expanding %+,
then we cannot bypass this expansion. Thus use:
pasted = paste_tokens(&thead, true);
if (expanded && pasted) {
... instead.
This seems to work with both Syslinux and x264 usage, and therefore
hopefully should be compatible with earlier versions of NASM.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
*To the best of my knowledge*, we now have authorization from everyone
who has significantly contributed to NASM in the past. As such,
change the license to the 2-clause BSD license.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Add copyright headers to the *.c/*.h files in the main directory. For
files where I'm sure enough that we have all the approvals, I have
given them the 2-BSD license, the others have been given the "LGPL for
now" license header. Most of them can probably be changed after
auditing.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
When processing an unparsable TASM argument, convert it to %if 0 which
is guaranteed to not happen, rather than %ifdef BOGUS.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Preexisting code seems to rely on %+ being processed even during early
token replacement, e.g. Syslinux contains the following code:
%macro superb 1
bx %+ %1 equ SuperInfo+($-superblock)*8+4
bs %+ %1 equ $
zb 1
%endmacro
... which is expected to work when invoked as:
superb Media
As a result, set handle_paste_tokens to true at all times; assuming
this turns out to be the way things are we can really just remove it
as an option.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Unify the token-pasting code between the macro expansion and the
preprocessor parameter case. Parameterize whether or not to handle %+
tokens during expansion (%+ tokens have late binding semantics.)
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Recognize $ and $$ as TOKEN_OTHER; they aren't really either
TOK_NUMBER nor TOK_ID, even though we have traditionally considered
them TOK_NUMBER.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
