The cast to char** is a violation of strict aliasing rules.
Compilers may generate incorrect code due to this issue.
Using memcpy to avoid the issue. Not expecting perf difference.
Move ABC_NAMESPACE_HEADER_START (and the abc_global.h include) before the
non-LFS prototype block so the bare gzFile references in gzopen64/gzseek64/
gztell64/gzoffset64 resolve to the namespaced type. Without this, building
with ABC_USE_NAMESPACE=xxx fails on platforms that compile this block (e.g.
macOS, which does not define _LARGEFILE64_SOURCE):
gzguts.h: error: unknown type name 'gzFile'; did you mean 'xxx::gzFile'?
Restores the header ordering used in the previous zlib 1.2.5 sources.
Signed-off-by: Matt Liberty <mliberty@precisioninno.com>
Sbl_CutIsFeasible only checked LutSize <= 4 before the final
return Count <= 6, allowing 6-input cuts when LutSize=5.
Add the missing LutSize <= 5 check after the 5th bit-strip.
The non-readline branch of Abc_UtilsGetUsersInput has three behavioral
gaps versus the readline branch that break callers driving abc as a
coprocess over a pipe (e.g. yosys's passes/techmap/abc.cc, which spawns
"abc -s" with piped stdin/stdout and uses read_until_abc_done to wait
for "abc NN> <command>" lines):
1. The prompt is written with fprintf() and never flushed. On a pipe
stdout is fully buffered, so the prompt never reaches the reader.
The reader waits for the prompt, abc waits in fgets(), deadlock.
2. There is no echo of the line read from stdin. readline() emits
each character to its output stream; yosys's protocol depends on
seeing "abc NN> source ...\n" in the output to advance state.
Without an echo it waits forever.
3. EOF on stdin is silently ignored: fgets() returns NULL but the
function returns a stale Prompt buffer, causing a tight loop on
pipe close. The readline branch exit(0)s on NULL.
Fix all three. Echo only when stdin is not a tty -- on a tty the kernel
already echoes typed characters during cooked input, so double-echo
would be visible to interactive users.
Signed-off-by: Matt Liberty <mliberty@precisioninno.com>
Get the fixes for CVE-2010-0405 & CVE-2019-12900. I have tried to
preserve the local modifications on top of the base library.
Signed-off-by: Matt Liberty <mliberty@precisioninno.com>
This seemly benign loop
```
for ( i++; i < p->nSize; i++ )
p->pArray[i-1] = p->pArray[i];
```
will actually load `p->nSize` in every loop iteration (rather than
memorizing the value) due to some unfortunate pointer aliasing properties
in C/C++. As Vec_IntRemove is quite ubiquitous, this extra memory load
actually causes visible performance impact and prevents further
optimizations on the loop.
This patch fixes this by factoring `p->nSize` out of the loop.