ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] [Wireshark-bugs] [Bug 1430] EtherCAT dissector

From: Jaap Keuter <jaap.keuter@xxxxxxxxx>
Date: Tue, 16 Oct 2007 18:51:15 +0200
Hi Ulf,

We've looked into this a while ago and it seemed that the WS_VAR_IMPORT stuff didn't work on data items shared between DLL's. If there's some new insight, please someone make it work. I've no Win32 platform to develop this on, and have no idea how to handle this tricky situation.

Thanx,
Jaap

Ulf Lamping wrote:
bugzilla-daemon@xxxxxxxxxxxxx schrieb:
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1430

------- Comment #46 from jaap.keuter@xxxxxxxxx  2007-10-16 08:24 GMT -------
(In reply to comment #44)
As /WX is already defined and this still not detects the unused variable I
tried /analyze instead. This shows that the declaration of the static const
true_false_string flags_set_truth in some of the files hides the declaration in
epan\tfs.h. When removing my own declarations of flags_set_truth, it just wont
compile any longer as flags_set_truth is not defined.
When looking in epan\tfs.h there is a comment for the flags_set_truth that
reads:
 * Old true_false_string from packet.c
 * Retained for backward compatibility until all dissectors are updated.

What is this? What update should be required in *all* dissectors?
flags_set_truth should be considered an alias to tfs_set_unset. That is what
the comment is referring to.
The main problem is that a plugin in a DLL (note this is a Windows only
problem) can't use these predefined true_false_strings, since the data resides
in another DLL. It's just a limitation of the Windows dynamic linker, which
other platforms don't have. So, the way to fix this is to include the declarations of the required TFS in
your plugin code wrapped in #ifdef _WIN32 ... #endif. This way it will be
compiled in locally in your Win32 plugin, while the other platforms just use
the provided strings from tfs.c. Sure, it's not so nice, but hey go complain to
Bill.
?!?

We use lot's of functions and also data (e.g. from libwireshark.dll) in plugins, so what's any different here?
BTW: You'll have to do somthing similar if you want to use the xdlc helper
functions in a plugin.