mbox series

[0/2] remove __typeof__ from expansion of per lcore macros

Message ID 1703006864-27378-1-git-send-email-roretzla@linux.microsoft.com (mailing list archive)
Headers
Series remove __typeof__ from expansion of per lcore macros |

Message

Tyler Retzlaff Dec. 19, 2023, 5:27 p.m. UTC 
  The design of the macros requires a type to be provided to the macro.

By expanding the type parameter inside of typeof it also inadvertently
allows an expression to be used which appears not to have been intended
after evaluating the parameter name and existing macro use.

Technically this is an API break but only for applications that were
using these macros outside of the original design intent.

Tyler Retzlaff (2):
  eal: provide type instead of expression to per lcore macro
  eal: remove typeof from per lcore macros

 lib/eal/common/eal_common_errno.c | 2 +-
 lib/eal/include/rte_per_lcore.h   | 8 ++++----
 2 files changed, 5 insertions(+), 5 deletions(-)

Comments

Bruce Richardson Dec. 19, 2023, 5:36 p.m. UTC | #1 
On Tue, Dec 19, 2023 at 09:27:42AM -0800, Tyler Retzlaff wrote:
> The design of the macros requires a type to be provided to the macro.
> 
> By expanding the type parameter inside of typeof it also inadvertently
> allows an expression to be used which appears not to have been intended
> after evaluating the parameter name and existing macro use.
> 
> Technically this is an API break but only for applications that were
> using these macros outside of the original design intent.
> 
> Tyler Retzlaff (2):
>   eal: provide type instead of expression to per lcore macro
>   eal: remove typeof from per lcore macros
> 
Series-acked-by: Bruce Richardson <bruce.richardson@intel.com>
David Marchand Feb. 13, 2024, 11:12 a.m. UTC | #2 
On Tue, Dec 19, 2023 at 6:28 PM Tyler Retzlaff
<roretzla@linux.microsoft.com> wrote:
>
> The design of the macros requires a type to be provided to the macro.
>
> By expanding the type parameter inside of typeof it also inadvertently
> allows an expression to be used which appears not to have been intended
> after evaluating the parameter name and existing macro use.
>
> Technically this is an API break but only for applications that were
> using these macros outside of the original design intent.

Please add a release note on this topic (I am fine with just a reply
to this mail, I can fold this change when applying).

The rest lgtm.