- Fix nasty problem with uninstaller in case of registry
keys corruption, which might lead to arbitrary files
removal.
Just to be sure the proper files and directories are to
be removed a few additional questions are brought into
deinstallation procedure.
The former issue reported here
http://forum.nasm.us/index.php?topic=1013.0
Note: no functional changes are done inside nasm code,
critical fixes will be ported to 2.09.xx branch, but
mostly the (more or less) active development and various
bug fixes are concentrated around 2.10 series.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
In case of installation procedure being used in
a per-user fasion the display link to a bat file
remain untouched at uninstallation time. Fix it.
I hope this time all things go smooth.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Since a user might have some weird access rules on NTFS
such as allow to write files but not to delete them it
might happen that uninstallation procedure fails at
deleting files but deleting registry keys still success,
and in result a user might try to uninstall nasm for second
time with registry keys corrupted.
So prompt a user with files being deleted so he can double
check what is going on.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
It was reported on nasm forum (http://forum.nasm.us/index.php?topic=1013.0)
that if uninstallation procedure get stopped (for any reason) in a middle
leading to read empty registry values an attempt to remove arbitrary
files might happen. So make sure there are some sane values in registry.
N.B: People, if you find some bug in nasm, don't write to forum, file
bug directly in bugzilla, if it's not a bug we simply close it, otherwise
we might miss serious problems like this one!
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
In case of installation procedure being used in
a per-user fasion the display link to a bat file
remain untouched at uninstallation time. Fix it.
I hope this time all things go smooth.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Since a user might have some weird access rules on NTFS
such as allow to write files but not to delete them it
might happen that uninstallation procedure fails at
deleting files but deleting registry keys still success,
and in result a user might try to uninstall nasm for second
time with registry keys corrupted.
So prompt a user with files being deleted so he can double
check what is going on.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
When we don't have an immediate for the i-field in /is4, then use a
normal quad-bytecode encoding for it to save some small amount of
space and re-use existing machinery.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
The DREX encoding never hit production silicon, and has been replaced
by VEX/XOP encoding, so remove support for it.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Clean up the formatting of the BMI instruction patterns, and fix:
a) X64,FUTURE is wrong - it needs to be LONG,FUTURE
b) Fix the BLSI, BLSMSK, BLSR instruction patterns
c) Use a bracket pattern for TZCNT
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
It was reported on nasm forum (http://forum.nasm.us/index.php?topic=1013.0)
that if uninstallation procedure get stopped (for any reason) in a middle
leading to read empty registry values an attempt to remove arbitrary
files might happen. So make sure there are some sane values in registry.
N.B: People, if you find some bug in nasm, don't write to forum, file
bug directly in bugzilla, if it's not a bug we simply close it, otherwise
we might miss serious problems like this one!
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>
Just a few fixes only but serious enough to yield
new stable series
- Unitialized memory parsing in bin format section attibutes.
- MachO NULL dereference
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Basically it's backport of commits
11db774a153bc3ff2fb6c13deef255e3f4780665
They were missed to back-merge in a first place.
Reported-by: Keith Kanios <keith@kanios.net>
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>
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>
This reverts commit cb00cd1ba7.
As Victor pointed out some tests do not pass with this commit
so revert it until things get fixed.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
It's a bit more than that, also TRACE=1 make
flag added to run this facility on and off
at compiling time.
Debug feature only, doesn't affect regular users.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
There is no way to make it as a helper function
for a while, we need to unify list processing
in general (ie to use abstract list type).
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
This allow us to write the whole expressions
on section alignments, such as
align 0xa+6
or whatever math. Should be a way more convenient
than hardnumbers scheme we had.
Reported-by: Frank Kotler <fbkotler@zytor.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
We simply allow the following terminals to be concat'ed
if they are written without space or any other separator
inbetween.
a := id | preproc-id | number | float | other
b := id | preproc-id | number | float | other
if match(a,b):
s := concat(a,b)
re-tokenize(s)
Basically it means it's up to code author to write
preproc code a way the sane production appears.
Some notes.
1) We don't concat strings.
2) The 'weirdpaste' test fails now because with relaxed
rules it works as needed and was borken before.
The lacmus snippet is
%define N 1e%++%+ 5
dd N, 1e+5
Previously the output was
dd 1e+%+ 5, 1e+5
which is wrong since we have explicit concat here
with %+ operator. The new code production is correct
and looks like
dd 1e+5, 1e+5
as expected.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
