memchr seems to have a bug on recent Linux systems if the count that is passed in is larger than the buffer (in our specific case the count is -1 to find the 0 byte of \0 terminated strings): the function "randomly" fails to find the byte and returns zero thus leading to for example incorrect parameter handling.
rtl/inc/cgeneric.inc:
* use rawmemchr on Linux if -1 is passed as count
git-svn-id: trunk@30160 -
multi-platform version of patch in r12461, which caused the i386 version
of fpc_pchar_length to return 0 in all cases, which used tabs, and did
not include a test case)
git-svn-id: trunk@12464 -
* math library is now automatically linked on non-x86 platforms when FPC_USE_LIBC is defined
* generic C system function signature adaptions for 64 bit CPUs
git-svn-id: trunk@1392 -
and also have full double support (exp() only has support for values in
the single range in genmath, for example). Used in FPC_USE_LIBC is
defined
* several fixes to allow compilation with -dHASINLINE, but internalerrors
because of missing support for inlining assembler code
* system.inc: include cgeneric.inc before powerpc.inc/i386.inc/... if
FPC_USE_LIBC is defined
* powerpc.inc, i386.inc: check whether the routines they implement aren't
implemented yet in another include file (cgeneric.inc)