In the implementation of mempcpy():
Doing arithmetic on (void *) isn't permitted, so we need to cast it to
(char *); it then get automatically converted to void * by the return.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
There is absolutely no reason not to include <string.h> globally, and
with the inline function for mempcpy() we need it there anyway.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
In list_emit we walk over listerr_head freeing the list,
but the head pointer remain carrying old value. Need
to clean it up once traverse is done to not access
already freed memory later.
https://bugzilla.nasm.us/show_bug.cgi?id=3392538
Reported-by: russvz@comcast.net
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
There is space in the token table to explicitly encode the size
corresponding to a size token. We might as well do so...
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Test case from bug 3392538 for double free in the listing module.
This is the test case only, not a fix.
Reported-by: <russyz@comcast.net>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
AMD documents this instruction with an rax operand. The error behavior
implies this is an address-size-sensitive instruction. Add support for
specifying the explicit operand, but consistent with normal ndisasm
behavior, don't disassemble the implicit operand.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
With buffered warnings, most warnings *must* be issued on every pass,
so ERR_PASS1 is simply wrong in most cases.
ERR_PASS1 now means "force this warning to be output even in
pass_first(). This is to be used for the case where the warning is
only executed in pass_first() code; this is highly discouraged as it
means the warnings will not appear in the list file and subsequent
passes may make the warning suddenly vanish.
ERR_PASS2 just as before suppresses an error or warning unless we are
in pass_final().
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
The use of pass0, pass1, pass2, and "pass" passed as an argument is
really confusing and already caused a severe bug in the 2.14.01
release cycle. Clean them up and be far more explicit about what
various passes mean.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
It is been discovered that on gcc-4.8.4 compiler can't
properly evaluate __builtin_constant_p.
| gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
|
| In file included from asm/nasm.c:38:0:
| asm/nasm.c: In function ‘assemble_file’:
| ./include/compiler.h:377:27: error: first argument to ‘__builtin_choose_expr’ not a constant
| # define if_constant(x,y) __builtin_choose_expr(is_constant(x),(x),(y))
| ^
| ./include/nasmlib.h:145:23: note: in expansion of macro ‘if_constant’
| static_assert(if_constant(x, 1), #x); \
| ^
| ./include/nasmlib.h:167:9: note: in expansion of macro ‘nasm_try_static_assert’
| nasm_try_static_assert(x); \
| ^
| asm/nasm.c:1544:17: note: in expansion of macro ‘nasm_assert’
| nasm_assert(output_ins.times >= 0);
|
Zap it for 4.x series so we could run our tests.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
