Wireshark-dev: Re: [Wireshark-dev] Wireshark ABI stability 1.6.4 -> 1.6.5
From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Fri, 13 Jan 2012 11:19:45 -0800
On Jan 8, 2012, at 12:08 PM, Balint Reczey wrote:

> I have run tools/git-compare-abis.sh on latest master-1.6 (wireshark-1.6.4-21-ga6c3642).
> 
> The ABI is almost totally stable [1], which is very good sign for plugin developers and for anyone using Wireshark's libraries.  :-)
> 
> There is only a minor incompatibility in packet-zbee-zcl.h caused by changed constants, which could be fixed by not backporting r40133.

Those constants are, I infer from the comment for the change:

> r40133 | alagoutte | 2011-12-09 09:00:28 -0800 (Fri, 09 Dec 2011) | 8 lines
> 

> From report of Arasch Honarbacht via https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6649
> ZigBee ZCL Dissector reports invalid status
> 
> The status code 0x8d contained in an attriute status record in a configure reporting response frame is incorrectly displayed as "Write only" (where WRITE_ONLY = 0x8f). According to the ZigBee Cluster Library Specification, Document 075123r03ZB, April 26, 2010 a status of 0x8d should display as "INVALID_DATA_TYPE"
> 
> From me :
> Fix this issue (Wrong value define) based on Specs available in ZigBee.org

definitions of protocol status codes, not constants used in APIs, so backporting the change won't introduce an ABI change.  (That header file should arguably be swallowed up into epan/dissectors/packet-zbee-zcl.c, which is the only place in Wireshark where it's included.  Given that we don't explicitly define the part of the plugin API that's defined by dissectors rather than by the libwireshark core, one disadvantage of having a dissector put protocol definitions etc. into a header file, even if they're not used by more than one dissector, is that automated ABI checkers can think they're part of the API and thus that changes to constants change the ABI.)