On Mon, Nov 04, 2024 at 08:15:00AM -0800, Stephen Hemminger wrote: > On Mon, 4 Nov 2024 13:11:02 +0100 > Morten Brørup <m...@smartsharesystems.com> wrote: > > > Unlike memcpy() and other copy functions, rte_ether_addr_copy() takes the > > destination as the second parameter. > > > > Not following well established conventions adds a high risk of causing bugs > > in the applications/libraries/drivers; it is likely that developers expect > > copy() functions to take parameters in the usual memcpy() order, and pass > > the parameters to rte_ether_addr_copy() in that order instead of the > > reverse order expected by rte_ether_addr_copy(). > > > > How can we fix this? > > > > One way would be to introduce a new copy function and mark the old function > > deprecated (due to risk of bugs). > > Does the community support such a change? > > And what would be a good name for the new function? > >
Include "memcpy" in the name instead of copy, to make the order of args clear? "rte_eth_addr_memcpy"? Other thought is to do a macro version of the function, which would mean that the name is capitalized. /Bruce
