On Wed, Mar 24, 2021 at 06:04:08PM +0100, Thomas Monjalon wrote: > 24/03/2021 17:45, Tyler Retzlaff: > > I understood this part. > > My question is more about the reason for having this define. > I think it is there because some compilers don't have asm keyword, > but have __asm__. And maybe that's the case for some C++ compilers. > If I'm right, this patch is breaking compilation with some > C++ compilers.
so to qualify. you mean maybe it is breaking compilation of c++ in a compiler that explicitly violates c++ standard when compiling c++? that would mean it is not a c++ compiler. in general i don't think it is a good practice to have dpdk introduce names into the application namespace unqualified, but the point you make is valid it can break c++ compilation if something was using this macro as a convenience to the compiler specific extension __asm__. there will be further issues with varying syntaxes that __asm__-style extensions take from compiler to compiler as well. would you prefer that i change the preprocessor protection to include only windows? since i'm certain that this will break for any c++ compiler on windows the moment any stl header is included. let me know how to adjust the patch i'll submit a new version. thanks!
