On Thu, Feb 25, 2021 at 12:31:33PM -0800, Nick Desaulniers wrote: > Q: But I put the `inline` keyword on the callee? > A: Probably deserves its own post, but the `inline` keyword doesn't > mean what any rational initial impression would suppose. Language in > the standard refers to "inline substitution" and grants a lot of > leeway to implementations in terms of whether it's performed at all.
That's just weasle wording to do the wrong thing :/ GCC (and other compilers) have been saying inline is a valid substitute for macros. You then reading the spec and saying we can do this ass backwards and screw everybody who's been expecting things to top-down is just not acceptible. The C spec is notoriously bad, because it fails to actually specify and then we get shit like this :-( And if you then take that 'freedom' and implement behaviour that 'doesn't mean what any rational initial impression would suppose', then you're just being a twat. Life is hard enough without compilers trying to screw you over on purpose :/ > There are cases where even with "always_inline" fn attr is applied, > and the compiler says "that's nice, but I still cannot perform inline > substitution here, I'm sorry." That's a hard fail from where I'm sitting. Can we please get a compiler error when that happens? That is, we're relying on this for correctness, if the compiler then goes and ignores it, we've got *serious* problems. This really MUST NOT happen. And I'm not joking, I can get you a non-booting kernel by removing just a few __always_inline in the right place. > There are no silver bullets here. It's semantics have > changed since its introduction, That isn't our doing, if the compiler redefines its keywords, don't tell us our program is broken. You're the ones that have been changing the meaning of thigs. > and I have seen rare uses that make my skin crawl. Do tell...
