Hello list, I wanted to report a minor issue that I stumbled upon in the course of testing.
PCRE (both 1 and 2) both use memmove(), and failing that, bcopy() or its own implementation. The system that I was testing on failed to detect memmove() due to a compiler issue, and so PCRE used bcopy() instead. However, I then encountered this error (with r979): .../pcre2/src/pcre2test.c: In function ‘process_data’: .../pcre2/src/pcre2test.c:6705: error: void value not ignored as it ought to be make[1]: *** [src/pcre2test-pcre2test.o] Error 1 The problem is that the code uses the return value from memmove(), but bcopy() does not return a value at all (void return type), so it cannot be used as a drop-in replacement for memmove(). The memmove() macro could be defined as #define memmove(a, b, c) (bcopy(b, a, c), a) to allow the code to compile, but this could be risky, given that "a" is evaluated twice. This appears to be a rare failure mode that has not been caught because very few systems lack memmove(). I would suggest something like moving bcopy() into the pcre2_memmove() function, along the lines of static void * pcre2_memmove(void *d, const void *s, size_t n) { #ifdef HAVE_BCOPY bcopy(s, d, n); return d; #else /* existing implementation here */ #endif } --Daniel P.S.: Please Cc: me on any replies, as I am not subscribed to this list. -- Daniel Richard G. || sk...@iskunk.org My ASCII-art .sig got a bad case of Times New Roman. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev