sycek doesn't accept `inline` functions in headers

[le-jzr]

sycek requires that inline function in a header must also be static, which prevents a legitimate use of inline.

Context:
Such a function is never emitted into object files unless an extern declaration is also present, in which case a global copy of the function is emitted. The standard way of using this is a non-static inline function with a body in a header, and corresponding extern declarations in some C file, ensuring that when inlining is not chosen by the compiler, there is only one copy of the function that is used by all non-inlined calls. It also ensures that taking the address of such a function returns the same pointer in all translation units.

[le-jzr]

I think the textual description is a bit hard to process, so here's an illustration:

header.h

inline void some_func(void) {
    // some implementation
}

cfile.c

#include <header.h>

// This compilation unit emits a global copy of some_func().
extern inline void some_func(void); 

user.c

#include <header.h>

int main() {
    // This call is either inlined, or links to the global copy of some_func() in cfile.o
    some_func();

    // indirect always points to the global copy in cfile.o
    void (*indirect)(void) = &some_func;
}

[jxsvoboda]

I am not convinced.

Firstly, ccheck is a style checker. We reject valid C code on purpose. The fact something is valid in C does no automatically mean it should pass style check.

I experimented with GCC 13.2.1 and if I have:

t.h:
#ifndef T_H
#define T_H

static inline int foo(void) { return 0; }

#endif

a.c:
#include "t.h"
int a(void) { return foo(); }

b.c:
#include "t.h"
int b(void) { return foo(); }

main.c:
void main(void) {}

and compile
gcc -O0 -c a.c
gcc -O0 -c b.c
gcc -o test a.o b.o main.o

then there will be only one function foo() called by both a() and b(). It might not be 100% guaranteed that there is just one copy of foo(), but why would I care? The compiler is smart enough to figure it out.

If you depend on &foo returning the same value all the time, I think you're doing something wrong.
In essence, for all practical purposes static inline and inline function seems like the same thing to me. If there are two different ways to do the same thing, it's a good idea to allow just one. Otherwise half of the functions would be inline and the other half static inline, without any system.

Finally, it is my plan to make either syc or ccheck (or both) warn about any use of 'extern' in a C file on grounds of modularity. Functions should only be declared in a module's interface header file. Not in a C file that uses the module. You could probably handle this as a special case, but it's just a complication. We should simply never see 'extern' in a .C file. They belong to .H files.

[le-jzr]

When you forbid a certain class of semantics from the code that has no valid way of being expressed, that's no longer a style issue.

[jxsvoboda]

'Semantic' means 'what is the behavior of the program'. 'Behavior of the program' means what output does it generate baed on what input. 'inline' does not change program behavior. Program behavior stays the same regardless how many copies of a function there are. It is just an optimization control. These days compilers are smart enough to know how to optimize the program (and I demonstrated this particular case). Therefore there is no need for the programmer to tell the compiler what to do. Therefore the programmer should NOT tell the compiler what to do. Therefore it should be a style issue.

[le-jzr]

"Semantic" literally means "meaning". That part of the semantics concerns behavior of a running program is incidental, not sum total of the concept. For a modern compiler to have the option to optimize the program as you say, the definition needs to be in the same translation unit. For such a function to occur in multiple translation units, it must be defined in a header as either static, or inline. Those two cases have different semantics. A static function will have a different address in different translation units, as you can easily demonstrate by printing said address using the address-of (&) operator. In contrast, a function declared inline with neither static or extern declarator may be used for inline expansion of the function invocation, but in cases where this is not done, as is the compiler's prerogative, the reference points to a single external definition, i.e. the address of this function will give the same address in all translation units. Therefore, the implementor must choose one of the following options:

• Accept that the function has different definition/address in every translation unit, which is not always desirable (and is contradictory to certain standards such as the C standard for standard library functions, as comparing function pointers for equality is a valid thing in C you can do.
• Accept that the function cannot ever be inlined, no matter how smart the compiler is.
• Use whole-program optimization, which involves additional complexity and performance impact on the compilation process, and doesn't work across shared library boundaries regardless.

I hope you can see now that the functionality that you dismiss is far from merely a stylistic issue.

[le-jzr]

Additionally, if you apply your argument consistently, then you have to conclude the difference between static and static inline is merely a style issue, and therefore the latter should be disallowed as well. Since there's no other use of the inline keyword you'd consider valid, the only logical conclusion of your argument is to ban the keyword inline altogether.