OK, now we are getting somewhere.
I must emphasise that the code in question is highly version-specific
Linux internal code which users are never supposed to see. For example,
it took me a fair bit of editing before I could make *gcc* accept the
header in question, on the Linux box I tried.
Also I tried using #ifndef S_SPLINT_S....but did not work. Still it
gives the same error.
Obviously you *DIDN'T* put that around the right code.
No this is not possible. In my case, I have a module having
more than 20 .c files and some of the .h files. In one of the
.h file I have included byteorder.h.
Yes, it *IS* possible to use S_SPLINT_S.
Here's what you do.
You say that ONE of the .h files includes byteorder.h.
(I stress once more that USER code should not be using this file.
User code should never mention type names like __u32.
I repeat that my copy of byteorder.h says
#warning using private kernel header; include <endian.h> instead!
User code should be using <byteswap.h> instead.
)
So there is ONE place where you have
#include <asm/byteorder.h>
So you change that to
#ifdef S_SPLINT_S
#define _I386_BYTEORDER_H
extern __u32 ___arch_swab32(__u32);
extern __u64 ___arch_swab64(__u64);
#define __arch_swab32(x) ___arch_swab32(x)
#define __arch_swab64(x) ___arch_swab64(x)
#else
#include <asm/byteorder.h>
#endif
But even if I remove this
file still splint gives same sparse error in byteorder.h.
That means byteorder.h is getting linked indirectly from any other .h
file I have included.
So find out which!
gcc -M foobar.c
tells you which headers (including system headers) foobar.c depends on.
Find a file where splint complains, use gcc to find which headers it
includes, and check each of them to see whether it mentions byteorder.h
_______________________________________________
splint-discuss mailing list
[email protected]
http://www.cs.Virginia.EDU/mailman-2.1.5/listinfo/splint-discuss
