In case if there is no environment variable present
we allocated empty string but when working with tokens
we test for second byte for special symbols, accessing
out of memory address (->text[1] for the reference).
http://bugzilla.nasm.us/show_bug.cgi?id=3392333
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
The codeview backend needs to be able to open each source file passed in
so that it can calculate its checksum. In order to take into account
include paths, this patch updates the filename to include the path where
the file was found.
Signed-off-by: Jim Kukunas <james.t.kukunas@linux.intel.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
[ hpa: resolved one conflict in preproc.c ]
The old code for keeping track of source file name and line was
confused as hell about ownership of the strings, and it is pretty
clear we leaked that information all over the place.
Instead, use a hash table to keep a copy of each string as necessary,
and simply make references to a string pool that we keep until the end
of the assembly session.
This pool probably should be unified with the list of dependency
files, and so on, but that is for the development branch.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
When assembling on Windows machines with CRLF line endings, computing
the MD5 hash from the file read in "text" mode (transforms CRLF->LF)
gives incorrect results.
Signed-off-by: Fabian Giesen <fabiang@radgametools.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
The hash calculation in calc_md5 tries to open the source file via
"filename" again. For %includes, this is the file name that was
specified in the %include directive, not the actual name of the file
that was opened by the preprocessor. In other words, this fails if the
include file is not in the current working directory.
Add pp_input_fopen that uses the preprocessor include path lookup
code to resolve a file name and open it, and use that in codeview.c.
Signed-off-by: Fabian Giesen <fabiang@radgametools.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Fix the printing of the macro stack: we need to follow the
mstk->next_active list, not mstk->next, and we need to reverse the
order so that the highest-level inclusion comes first.
Since this should be a rare or at least performance-insensitive
operation, do it using simple function recursion.
Finally, add an ellipsis before the "from macro" message; it greatly
enhances readability.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
It can be hard to find errors inside potentially nested macros.
Show the mmacro expansion stack when printing diagnostics.
Note that a list file doesn't help for errors that are detected
before the code-generation pass.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
The logic for suppressing preprocessor errors was missing an !, which
was present before checkin 215186fe82.
Reported-by: Knut St. Osmundsen <bird-nasm@anduin.net>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
For consistency with ofmt/dfmt, change the listing structure
to "struct lfmt" and "lfmt" and move it to listing.h.
From master branch commit 8ac25aa020
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
We pass around a whole bunch of function pointers in arguments,
which then just get stashed in static variables. Clean this mess
up and in particular handle the error management in the preprocessor
using nasm_set_verror() which already exists.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
From master branch checkin 130736c0cf
Resolved Conflicts:
nasm.c
preproc-nop.c
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Replace all instances of ERR_FATAL or ERR_PANIC with nasm_fatal or
nasm_panic so the compiler knows that these functions cannot return,
*and* we trigger abort() if we were to ever violate that constraint.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Once we free allocated memory don't forget to setup variables
to NULL, otherwise they are pointing into nonexisting memory,
which might lead into sigsegv in best case.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Multi-line macro uses curly braces for enclosing a parameter
containing comma(s). Passing curly braces as a part of a parameter
which is already enclosed with braces confuses the macro expander.
The number of braces in a group parameter is counted and any brace
in the outmost enclosing braces is treated as a part of parameter.
e.g.) mmacro {1,2,3}, {4,{5,6}}
mmacro gets 2 parameters of '1,2,3' and '4,{5,6}'
Signed-off-by: Jin Kyu Song <jin.kyu.song@intel.com>
This reverts commit a800aed7b7.
As recommended by the community, braces inside a group parameter
of multi-line macro should be parsed without a need of a leading
escape character such as "\{ab,c\}".
Signed-off-by: Jin Kyu Song <jin.kyu.song@intel.com>
Giving a correct printf format specifier supresses the warning message.
And a local pointer variable is initialized with NULL.
Signed-off-by: Jin Kyu Song <jin.kyu.song@intel.com>
Multi-line macro uses curly braces for enclosing a parameter
containing comma(s). Passing curly braces as a part of a parameter
which is already enclosed with braces confuses the macro expander.
Escape character '\' is prefixed in this case.
e.g.) mmacro {1,2,3}, {4,\{5,6\}}
mmacro gets 2 parameters of '1,2,3' and '4,{5,6}'
Signed-off-by: Jin Kyu Song <jin.kyu.song@intel.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
In commit f1fe4fdeab I occasionally
made a \Space after \BackSlash being a sign of line continuation.
Fix it.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
This should make it easier to read and moreover
now we're able to preprocess pasting as
%define N 1e%++%+ 5
dd N, 1e+5
Note that N should be expanded as series of pasting
to 1e+5 term, but before this patch we were ending
up in 1e+%+ 5 which is wrong.
In other words the fixed version output is
dd 1e+5, 1e+5
while broken one was
dd 1e+%+ 5, 1e+5
This patch also fixes nil dereferences in case if
there is no left or right token around pasting term.
http://bugzilla.nasm.us/show_bug.cgi?id=3392207
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
[backport 290eac7569]
2.09 series was the last one we support context-thru search
(and we were issuing a warning about that) so drop all-context
from get_ctx() routine.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
The NASM 2.09 preprocessor allows some illogical constructs, but which
unfortunately has been found in real code in the field. We need
a compatibility solution or a pragma before we can avoid that.
However, we need the other features in NASM 2.10 to come out, so
revert the preprocessor changes for now.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
It is a potential place for a bug if list_for_each
helper is used with multiple lines of code without
a proper bracing.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
In case if there a trailing spaces after expansion
%if[n]def might produce a false alarms on macro id
being expected.
Note it also makes the constructions like bare
%ifdef
%endif
invalid, while before they were passed well without
a notice.
Reported-by: KO Myung-Hun
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
new_ExpDef does zalloc'ate memory so no need
to assign zeros again.
Same time it should fix MSC complains on NULL assignment
on boolean variable.
Reported-by: Jasper Neuman <jasper.neumann@web.de>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
There is no need to hide this structure into a type.
The former preproc_ops is a way more descriptive.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
