Wireshark-dev: [Wireshark-dev] Interesting name collision
From: Eloy Paris <peloy@xxxxxxxxxx>
Date: Fri, 2 May 2008 11:06:20 -0400
Hi developers, Just wanted to share an experience that happened to me while using libwireshark from an application outside of the wireshark source tree: So I have this application I'm working on that uses libwireshark for all packet dissection tasks. My application also crafts packets. For a long time I was seeing that libwireshark was telling me that received packets had incorrect IP, TCP and UDP checksums. I couldn't figure out why because everything looked fine after dissection (correct field values everywhere) and the same packets dissected outside of my application showed correct checksums. It turns out that the problem was that libwireshark was calling the incorrect checksumming function due to a name collision with a function provided by my application. The function in question is in_cksum(). libwireshark's in_cksum() has the following declaration: int in_cksum(const vec_t *vec, int veclen); and my application's in_cksum() has: uint16_t in_cksum(uint8_t *data, size_t len); I am linking against libwireshark but the in_cksum() that gets used by both my application and libwireshark is my application's in_cksum(). Coincidentally both functions take similar arguments (a pointer and a length) so the end result was incorrect checksums instead of a crash. This was a bit difficult to track down because there are no compiler or link warnings, and running the application through a debugger will tell you that in_cksum() is getting called but the return value is misteriously incorrect. Anyway, my problem is now resolved - I just renamed my in_cksum() to avoid the name collision. However, I wonder if in order to prevent this from happening to others in the future you guys would be amicable to renaming epan's in_cksum() to something less likely to cause name collisions, like epan_cksum() or something like that. After all in_cksum() is a very generic and widely used name for an Internet Protocol checksumming function (it's in kernels, books, other projects, etc.) Another solution would be to make libwireshark's in_cksum() a private function, but this is not possible, is it? I mean, once you have a function defined in a separate source code file and you call it from other source code files the function becomes a public function, at least in the case of an application or shared library, or not necessarily? Cheers, Eloy Paris.-
- Prev by Date: Re: [Wireshark-dev] ADNS alternative
- Next by Date: [Wireshark-dev] buildbot failure in Wireshark (development) on OSX-10.4-PPC
- Previous by thread: Re: [Wireshark-dev] ADNS alternative
- Next by thread: [Wireshark-dev] buildbot failure in Wireshark (development) on OSX-10.4-PPC
- Index(es):
- Get Wireshark
- Download
- Code of Conduct