ludocode / mpack

MPack - A C encoder/decoder for the MessagePack serialization format / msgpack.org[C]
MIT License
521 stars 82 forks source link

Suggestions for warnings? #87

Closed schmidtw closed 2 years ago

schmidtw commented 2 years ago

I'm getting implicit-function-declaration warnings from both clang and gcc around the macro expansion for the MPACK_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 includes string.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?

../src/mpack/mpack.c:2321:5: warning: implicitly declaring library function 'memmove' with type 'void *(void *, const void *, unsigned long)' [-Wimplicit-function-declaration]
    mpack_memmove(reader->buffer, reader->data, left);
    ^
../src/mpack/mpack.h:1065:23: note: expanded from macro 'mpack_memmove'
#define mpack_memmove memmove
                      ^
../src/mpack/mpack.c:2321:5: note: include the header <string.h> or explicitly provide a declaration for 'memmove'
../src/mpack/mpack.h:1065:23: note: expanded from macro 'mpack_memmove'
#define mpack_memmove memmove
                      ^
ludocode commented 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.

schmidtw commented 2 years ago

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!

schmidtw commented 2 years ago

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.