Several issues were found in recent cygwin/ubuntu distros:
1. Newer git implements "-c" with different meaning, removes it;
2. "tempfile" is mostly debian specific command, replaces it with
"mktemp -u", the latter is more portable.
Singed-off-by: Lv Zheng <lv.zheng@intel.com>
Cannot be a resource descriptor if the declared buffer length is
not the same as the length of the buffer initializer list. For
a resource descriptor, both values will always be equal.
1) Only detect unicode if all buffer characters are printable ASCII.
Prevents some false positives.
2) Do not detect a string for buffers that contain 0x79, 0x00
because this is a resource descriptor EndTag, and will cause
a false postive for a string.
This is more to the spirit of the ACPI spec, even though it
is not explicitly stated what a "hexadecimal string" is.
However, a hex string is defined in ToInteger to be prefixed
with 0x. Other ACPI implementation already add the 0x, so
this also fixes a compatibility issue.
Using of temporal file name functions can easily result in bus errors on
MacOSX. This patch implements anonymous semaphore using an automatic
increasing number. Lv Zheng.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Fixes a problem with complex expressions where an illegal mix
of legacy ASL and ASL+ could be emitted.
Adds new support for ASLTS that disables some disassembler
optimizations could be changed during a conversion to ASL+.
These expressions are now emitted in legacy ASL instead
of ASL+.
During conversion of Else...If sequences to ASL ElseIf statements,
blocks of code can become detached from the parse tree and lost.
This change fixes the problem.
LoadTable allows an alternative RootPathString than the default "\", while
the new table execution support fails to keep this logic.
This regression can be detected by ASLTS - TLT0.tst4, this patch fixes this
regression.
Linux upstream is not affected by this regression as we haven't enabled the
new table execution support there. BZ 1326, Lv Zheng.
Link: https://bugs.acpica.org/show_bug.cgi?id=1326
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
LoadTable opcodes require acpiexec to build OEM tables in RSDT/XSDT.
However, during the EFI porting, OEM test table loading becomes an optional
behavior for acpiexec.
As ASLTS requires the OEM test tables, disabling this option by default
triggers the regression for ASLTS, causing LoadTable related cases to fail.
This patch fixes this regression by enabling this option for ASLTS.
Link: https://bugs.acpica.org/show_bug.cgi?id=1327
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
The following build errors can be seen for MacOSX builds:
.../osunixxf.c:882:9: error: 'sem_close' is deprecated [-Werror,-Wdeprecated-declarations]
.../acmacosx.h:122:29: note: expanded from macro 'sem_destroy'
#define sem_destroy sem_close
sem_destroy() issue is caused by the wrong order of the following lines:
#define #sem_destroy sem_close
#include <semaphore.h>
This patch fixes it by removing the buggy re-definitiion. Lv Zheng.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
The following build errors can be seen for MacOSX builds:
.../osunixxf.c:829:42: error: 'tmpnam' is deprecated: This function is provided for compatibility reasons only. Due to security concerns inherent in the design of tmpnam(3), it is highly recommended that you use mkstemp(3) instead. [-Werror,-Wdeprecated-declarations]
tmpnam should NOT be used and provides an easy and obvious privilege
escalation attack point. There is no advantage or compatibility reason to
use this function on OS X, and it correctly throws an error if its use is
attempted. Simply replacing it with mktemp, which behaves identically to
tmpnam, only with responsible protection against interprocess attacks. It
will behave identically if given NULL, and will fail in exactly the same
way, so there is no danger in switching to this function.
It's also safely tucked away in a specific #ifdef __APPLE__ block anyway,
so the scope of this change is perfectly controlled.
Signed-off-by: metacollin <metacollin@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
