Linux Networking Performance To Improve Thanks To Retpoline Overhead Reduction

[Weasel]

They should die because they come with a lot of problems but aren't dead because of their remaining usecases indeed. That was my point

There's no problem with macros except the fact they pollute everything in scope (more than even the global namespace). Every other problem is just idiots misusing them because that's what idiots do.

[Michael]

Of all the spectre testing, I don't remember seeing the performance impact on network throughput in your tests Michael - Once this lands are you able to give us a quick round of tests demonstrating the perf impact ? (I am sure you are already planning it, but if you needed an excuse to do it then count this as a request for it!)

Already building a patched kernel to see if my network tests pick up the impact.

[boxie]

Already building a patched kernel to see if my network tests pick up the impact.

sweet!

[DrYak]

There's no problem with macros except the fact they pollute everything in scope (more than even the global namespace). Every other problem is just idiots misusing them because that's what idiots do.

Simple (valid, compilable) example :

void myfunc(int,int,int,int);

#define MY_MAC ,a,b
/* ^- notice the commas */

myfunc(c /* notice no comma here */ MY_MAC + d, e);
/* ^- here the syntax analysis of your IDE (or your static analysis tools) panics about wrong signatures, */
/* unless it relies on some LLVM-based realtime incremental compilation */
/* Whereas your GCC/Clang will happily compile it */

Though usually nobody with a sane mind will attempt to do that in the real world.
(disclaimer: I am guilty of having actually sinned this way is some desperate duck-taping moments in the past)

There's a fundamental problem with macros :
- they basically enable you to copy-paste random arbitrary strings of ASCII wherever in your code (they don't follow C/C++ grammar, they follow their own independent CPP's grammar which could be split in completely different way)
- whereas C++ template as C++ citizen that follow C++ compatible grammar
- it's impossible to guess what a macro will do simply by glancing the source, you need to pre-process first (do the copy-pasting) to then guess.
- whereas template can only be instantiated into actual valid members of expression: it will instantiate into a function call whose's return value would be used as an argument for another function call). There are all valid C++ entities. There's no "pasting in some arbitrary chunk of text that then needs to be parsed as C/C++ source).

It's basically like Perl.
Yes it can be used in a civilized manner if you restrain yourself to use only sane bits.


But it can always be abused in creatively insa̍ͅn͎̆̒e̹̓̎ ͕͆e̟̻̜͑ͥ͋̔l̜̏̔d̦̰̓̓ͭͮͣ͘r̳̬̼͔̟̗ͪ̋ͫͮ̅̀͏i̷̻̥̲ͯ̓̑ͩ̒ͦtͨ ͎͉̞̱͔̯̥ͭ̋̒͠c̢̰̲̟͈̪͓̙͊ͅḩ͙͇͔̻ͣ͂̀ ̨̹̱̻̻͙̳͙̭̟̾͋̃͋̍̐͝ä͔̱̰̭̥́̑ͨ͟͞b̶̨̖̳̭̥̣͓̺̔̽ͨo̪̺̻ͥ̂̓ͦ̇ ̣͞m̡͕̦̭͊ͩ̌̓ͩ͒͟i̴͇̹͕ͥ̐ͥ̓ͨ͒͐̎n̤̲̖̹̥̲̤̮͓͛̿̋͂͘a̘̪̾͑ͧ̎̋ ̛̛͔͖̼̬̪͎t͓͙̥̻̬͖̥̦̙̦͌́̽̇͐̋͢ḭ̼͓̹͉͓̭͎͙̥̹͔̎ͯ͒͌ͬ͗̕͜͡oͭ ̘̭͔̋̌̋ͣ̐ͯ̃ͯ̆̉ͤ͗͛̽́͘ṉ̵̷̲̟̹̘̙̞̟̪̣̔͆͛̈̓ͦ͛ͪ͛ͭ͝s͛ͭ̃ͩͤͣ ̸̡̺̣̻͓͓̻̹͚̬͐̉̏ͬ̌ͪ̆͂̀ͅ.̸̗̬̬̿͐ͩ̓̐̅̏̿̔͌̚̕̕



---

(disclaimer: I also code in Perl. But there's no way you'll be able to hold it against me. You will never prove if I'm actually guilty of sinning, or if it's just my cat walking across the keyboard)

[Hi-Angel]

Simple (valid, compilable) example :

void myfunc(int,int,int,int);

#define MY_MAC ,a,b
/* ^- notice the commas */

myfunc(c /* notice no comma here */ MY_MAC + d, e);
/* ^- here the syntax analysis of your IDE (or your static analysis tools) panics about wrong signatures, */
/* unless it relies on some LLVM-based realtime incremental compilation */
/* Whereas your GCC/Clang will happily compile it */

Though usually nobody with a sane mind will attempt to do that in the real world.
(disclaimer: I am guilty of having actually sinned this way is some desperate duck-taping moments in the past)

Actually, in a project I'm working on we're extensively using a similar macro:

 #define box2args(box) box.begin(), box.end()

I haven't heard of any problems caused by it. I'm using Emacs with flycheck-mode, and my colleagues are using QtCreator.

I admit though it can easily go wrong if you pass an argument with a comma, and that's in particular why I said that C++ has very bad macros support. But when you bear in mind to not pass commas and temporary objects, it really simplifies the code.

[DrYak]

Actually, in a project I'm working on we're extensively using a similar macro:

#define box2args(box) box.begin(), box.end()

Which you can break (or abuse creatively) by passing "box2args(arg, box)" which will generate the non obvious "arg, box.begin(), arg, box.end()" (which could even have a practical use).

I haven't heard of any problems caused by it. I'm using Emacs with flycheck-mode, and my colleagues are using QtCreator.

Note I didn't say the code is invalid. It's perfectly valid and compilers will swallow it happily (note that both the tools you mention use a whole frigging compiler under the hood, either GCC or CLang).
But direct inspection of the code (by a simpler non-compiler-based tool or by a human) might not reveal what it actually does.

In short, C/C++ macros violate the "principle of least astonishment".

That's not a big problems per se (Hey, I'm the kind of guy who's all in favour of having ternary operators in my languages !)
But that simply explains why some people dislike macros to the point of wanting them gone.

I admit though it can easily go wrong if you pass an argument with a comma, and that's in particular why I said that C++ has very bad macros support. But when you bear in mind to not pass commas, it really simplifies the code.

That's the crux of the problem:
You have to keep thinking about some peculiarity (or enforce them using "#define sum(a,b) ((a)+(b))" parenthesis constructs).
There are some very non-obvious weirdness that unexpecting people might miss.

Basically macros are on the harsher side of the "Python to Perl" continuum.

[Hi-Angel]

Note I didn't say the code is invalid. It's perfectly valid and compilers will swallow it happily (note that both the tools you mention use a whole frigging compiler under the hood, either GCC or CLang).
But direct inspection of the code (by a simpler non-compiler-based tool or by a human) might not reveal what it actually does.

In short, C/C++ macros violate the "principle of least astonishment".

That's not a big problems per se (Hey, I'm the kind of guy who's all in favour of having ternary operators in my languages !)
But that simply explains why some people dislike macros to the point of wanting them gone.

Well, it's not necessary to want them gone, just to improve them. For example Rust has macros support, but none of those problems happens there.

Anyway, I was just wondering, what IDE breaks upon meeting such a syntax?

[DrYak]

Anyway, I was just wondering, what IDE breaks upon meeting such a syntax?

Basically, anything that is NOT compiler base.

Quite from the top of my head:
- Microsoft Visual things (at least back when I tried them last, they were definitely NOT compiled based). But breaking in ridiculous way has always been MS' national sport anyway.

And rule-based syntax highlights/analysis:
- Scintilla-based syntax highlights (SciTE, Kate) though they usually degrade nicely (short of having macros with stray parenthesis. But those are a very special kind of evil {*}).
- simpler highlights like nano

etc.

Also tools that directly analyse the source code files (without a compiler) like Coccinelle


The short version is that macro make it possible to "break" the syntax in a C/C++ file and tools that rely on the syntax of files (As opposed on calling the compiler that will do all pre-processing) will break.

-----

{*} there was a special GPGPU system (I think it was BrookGPU) that works by ginormous amount of creative abuse of both macro AND templates.
Some capital reserved word (like "IF", "FOR", "WHILE") actually expands into a complicated macros that will capture the content of the blocks and have the GPGPU system generate GPU code at runtime instead of being compiled by the C compiler at compile time.
Basically, it enables a separate-source GPGPU platform to pretend being a single-source GPU.

Or, in other words, it purposefully uses the "syntax breaking power" of macros to actually break the C++ syntax and enable something reminiscent of CUDA ... without leaving the comfort of your C++ compiler.

[Weasel]

Simple (valid, compilable) example :

void myfunc(int,int,int,int);

#define MY_MAC ,a,b
/* ^- notice the commas */

myfunc(c /* notice no comma here */ MY_MAC + d, e);
/* ^- here the syntax analysis of your IDE (or your static analysis tools) panics about wrong signatures, */
/* unless it relies on some LLVM-based realtime incremental compilation */
/* Whereas your GCC/Clang will happily compile it */

Though usually nobody with a sane mind will attempt to do that in the real world.
(disclaimer: I am guilty of having actually sinned this way is some desperate duck-taping moments in the past)

That's one of the misuses, however in your case since you had to duck-tape it, then clearly macros are GOOD for allowing you to do it and save a lot of time in the process (that's why you abused them that way).

But most macros -- the non-misused type -- are ok... except that they pollute all scopes, which is really what gets to me.

Yes macros do text substitution. The whole point of macros is to extend syntax and that's why they are good. They automate syntax that otherwise wouldn't be possible. People use them because the default syntax is too limited in some cases.

For example, my favorite use of macros, the X macro.

[funkboy]

This is great, thanks for posting.
But will Wireguard finally make it into 4.21? Anybody taking bets?