OSX: 13.2 (22D49)
Apple clang version 14.0.3 (clang-1403.0.22.14.1)
Target: arm64-apple-darwin22.3.0
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
I have tried to fix it, but some issues remain.
If you like, I can make a fork and pull request for the fork? it contains some fixes I made to let it compile better. Just some missing headers. For example, it could not find malloc. But even after those fixes, it has issues I could not fix. Here below:
turborc.c:390:1: error: call to undeclared function 'rcrzsenc8'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
RCGEN2(rcrz, 8)
^
turborc.c:339:31: note: expanded from macro 'RCGEN2'
case RC_PRD_S : return p##senc##s( in, inlen, out);
^
:246:1: note: expanded from here
rcrzsenc8
^
turborc.c:390:1: error: call to undeclared function 'rcrzssenc8'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
turborc.c:340:31: note: expanded from macro 'RCGEN2'
case RC_PRD_SS: return p##ssenc##s(in, inlen, out, prm1,prm2);
^
:248:1: note: expanded from here
rcrzssenc8
^
turborc.c:497:70: error: call to undeclared function 'rccdfsmenc'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
case 44: TM("44:cdfsm static/decode division lut ",l=rccdfsmenc(in,n,out,cdf,m+1),n,l, CCPY:(m<16?rccdfsmldec(out,n,cpy, cdf, m+1):rccdfsmbdec(out,n,cpy, cdf, m+1))); break;
Architecture detection seems to look for aarch64 but not arm64, which is what the machine returns for uname -s
Frame pointers shouldn't be omitted for any macOS binaries
There are many system headers that needed to be included to different files, or else add CFLAGS+=-Wno-implicit-function-declaration
Issue with sse_neon.h:
./include_/sse_neon.h:232:85: error: invalid conversion between vector type 'uint64x2_t' (vector of 2 'uint64_t' values) and 'uint8x8_t' (vector of 8 'uint8_t' values) of different size
static ALWAYS_INLINE uint64_t mm_movemask4_epu8(__m128i v) { return vgetq_lane_u64((uint64x2_t)vshrn_n_u16((uint8x16_t)v, 4), 0); } //uint8x16_t
Issue of using __m128i for arm64:
./include_/bitutil_.h:128:77: error: returning 'int' from a function with incompatible result type 'uint32x4_t' (vector of 4 'uint32_t' values)
static ALWAYS_INLINE __m128i mm_delta_epi64(__m128i v, __m128i sv) { return _mm_sub_epi64(v, _mm_alignr_epi8(v, sv, 8)); }
these encoders can write past end of buffer. Is there a maximum over-run?
This seems to fix over runs:
#define OVERFLOW(in, inlen) if(op >= out+inlen-16) { memcpy(out, in, inlen); return inlen; }
It seems cleaner to specify the outlen as a parameter (inlen for decompress).
outlen might be reduced externally for application reasons and internally for maximum overrun.
Omitting the memcpy()
#define OVERFLOW(in, inlen) if(op >= outbound)return 0;