Closed schmidtw closed 2 years ago
Hmm, that's weird. memmove()
should definitely be in string,h
.
What platform are you on? Is it possible you're using an esoteric platform or C library that defines memmove()
elsewhere? Could it be disabled in favor of some other function like memmove_s()
? Do you maybe have a macro defined on memmove
? I'm not sure what could cause memmove()
to be missing without also losing memcpy()
, strlen()
, memset()
, etc.
I would recommend looking at the preprocessed output to see what's going on with string.h
. If you can give me more info about your platform I can try to reproduce it here.
Good question on the environment ... I should have mentioned that. I' building using a sock Fedora Linux 34 environment. For other files, including string.h
does what you'd think.
Good suggestion on the preprocessed output. I'll dig in. I'll also get the code in shape enough to push to a branch so it's easier to see what all is going on.
Thanks!
This turned out to be a build configuration error :). I inadvertently included the local source directory path in with the system includes & I happened to have a string.h file present locally that was being loaded instead of the system file.
mpack is now compiling cleanly. Great question - it helped me get out of my rut.
I'm getting
implicit-function-declaration
warnings from bothclang
andgcc
around the macro expansion for theMPACK_STDLIB
. I'm using 1.0 release code. Both amalgamation and from git have the same issue.This warning is from when I compile the mpack.c file with all warnings enabled. By inspection
mpack.h
includesstring.h
and should be fine, but I've also added#include <string.h>
at the top of both mpack.c and mpack.h and still get the warning.Any suggestions?