Re: Why isn't libwireshark.def autogenerated?

[Andreas <AndreasSander1 () gmx net>]

Am 18.12.2010 00:48, schrieb Gregory Seidman:
> On Fri, Dec 17, 2010 at 03:40:55PM +0100, Balint Reczey wrote:
> > Hi Gregory,
> >
> > On 12/17/2010 03:21 PM, Gregory Seidman wrote:
> > > I keep running into this issue where I'm working on a dissector plugin
> > > (for internal distribution, on Windows) and want to use some function
> > > declared in a header file in epan or epan/dissectors only to discover
> > > that it won't link. Even if I modify libwireshark.def in my source tree
> > > so the plugin will link, it will fail to load in any other build of
> > > Wireshark (e.g. the standard release).
> >
> > Symbols listed in libwireshark.def are the symbols provided for external
> > use. We should not list symbols not exported from libwireshark in headers
> > provided for plugin development, I agree.
>
> And vice versa: symbols listed in headers should be exported.



> > The point of having libwireshark.def (and libwireshark.sym from now) is
> > to list the symbols we consider to be part of the public API (ABI). We
> > can keep those symbols reasonably stable while we are free to change the
> > internal symbols frequently. Please don't provide a patch for exporting
> > all symbols, but name the symbol you miss from libwireshark.def.
>
> I would argue that if a function is in a header file in epan or
> epan/dissectors, it is part of the public API. Perhaps only headers in epan
> and packet-*.h headers in epan/dissectors. It's not that every non-static
> symbol should be exported, but that every symbol declared in a header file
> is part of the public API and should therefore be exported.

The problem I see is that Wireshark doesn't have "The API". It is not 
obvious which header files, and which declaration are public. When you 
look at the libwireshark.def it seems that definitions have been added 
or removed just as the needs appeared.

For example in rev 34876 the function proto_item_append_string is added 
to the exported functions. The header file proto.h that declares (and 
documents) this function is not changed since rev 34466. So I can't 
think of any reason to add this symbol to the export list than that 
anybody was asking for it.

I would propose to _define_ the Wireshark API. This will be a process 
and I don't expect this to become available in a few days. One way to 
identify *the Wireshark API* would be to identify this API in the header 
files.

With a central macro WIRESHARKAPI(or WSAPI

// config.h

#ifdef MSVC_VARIANT
// generating libwireshark.DLL
   #ifdef _NEED_VAR_IMPORT
     #define WIRESHARKAPI __declspec(dllimport)
   #else
     #define WIRESHARKAPI __declspec(dllexport)
   #endif
#else
   // not generating DLL
   #define WIRESHARKAPI extern
#endif

you can define the API in the header files like this:

// proto.h

WIRESHARKAPI proto_tree* proto_tree_create_root(void);

WIRESHARKAPI proto_item *
proto_tree_add_item(proto_tree *tree, const int hfindex, tvbuff_t *tvb,
     const gint start, gint length, const guint encoding);

The has some advantages

- one central place to define how the functions become part of the API 
in config.h

- exactly one place of definition if a symbol is part of the API.
Currently you define the symbol in header and DEF file.

- It is visible immediately if a declaration in the header files is part 
if the API or not.

What do you think about it?


--
Andy

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe