Risk of rte_ether_addr_copy() causing bugs

[Morten Brørup]

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?

Any other ideas for fixing it?


Med venlig hilsen / Kind regards,
-Morten Brørup