On Tue, Aug 8, 2017 at 11:02 AM, Van Haaren, Harry < harry.van.haa...@intel.com> wrote:
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of David Harton > > Sent: Monday, August 7, 2017 6:39 PM > > To: tho...@monjalon.net > > Cc: dev@dpdk.org; David Harton <dhar...@cisco.com> > > Subject: [dpdk-dev] [PATCH v3] ethdev: add return code to > rte_eth_stats_reset() > > > > Some devices do not support reset of eth stats. An application may > > need to know not to clear shadow stats if the device cannot. > > > > rte_eth_stats_reset is updated to provide a return code to share > > whether the device supports reset or not. > > > > Signed-off-by: David Harton <dhar...@cisco.com> > > --- > > Hi, > > As far as I know changing the return type (void to int) of a function does > *not* break ABI, but does "break" API as the application code should now > check the return value. In theory the application could ignore the return > value and current behavior is maintained. > After discussing with Harry on IRC it turns out we both ended up checking the same online sources to verify our thoughts, like [1]. Given this and several other sources it seems to be as outlined above an API but not ABI break. I'm not an expert and this is mostly opinion, but my personal rule mostly is: "if in doubt bump it". Running similar issues I was the one providing [2] for a reason, with this here being a case that appears safe but there eventually always seems to come up an architecture or alternative compiler which does some arcane register juggling differently and makes those "safe" changes breaking people after the fact. [1]: https://stackoverflow.com/questions/15626579/c-abi-is-it-safe-to-change-void-function-to-return-int [2]: http://dpdk.org/doc/guides/contributing/versioning.html#setting-a-major-abi-version
