One possible solution would be to compile all of the code with clang. This, of course, would result in a library that is now incompatible with other code compiled with the C compiler. That can be worked around. Unfortunately, it also appears that clang is not quite ready to take on the task of a general-purpose C compiler. These are some of the issues I have encountered.
- Clang does not appear to use any logical names when deciding which directories to search for included files. Based on my experience, it only searches those directories specified on the command line or in an include-directory pragma.
- Clang does not appear to search the directory of the including file first before using the command line. This causes problems when the filename being included appears in multiple directories.
- Clang does not know how to find the variants of at least some functions when there are 32 and 64 bit versions. They must be explicitly specified. The following is an example.
Code: Select all
$ type test.c #include <string.h> void copyit( char * src, char * dst, size_t size) { memcpy(dst, src, size); } $ cc test $ clang -pointer-size=32 test.c test.c:6:19: error: too many arguments to function call, expected 2, have 3 memcpy(dst, src, size); ^~~~ 1 error generated. $ $ type test.c #include <string.h> void copyit( char * src, char * dst, size_t size) { _memcpy32(dst, src, size); } $ clang -pointer-size=32 test.c $
From a user perspective, the best fix would seem to be to add a switch to the C compiler that would cause it to treat all data types the same as the C++ compiler. I'm not sure how VSI would feel about that. The alternative would be to make clang a supported compiler for C code.
Any hints on what direction I should be pursuing when resolving these issues when mixing C and C++ code would be most welcome.