On 5/5/23 18:47, David Brown via Std-Proposals wrote:
[...]

>>> and then the
>>> "inline" modifier is pretty much redundant except to tell readers that
>>> this is something you view as a small helper function
>>
>> Yes, inline is redundant in static inline. I never write static inline
>> functions, since I would only write them in .c files, but then static is
>> enough.
>
> I, on the other hand, never use "inline" on a function that is /not/
> static. I always know if the use of the function would require using a
> non-inline external definition. (Note that it's fine by me if the
> compiler chooses to generate fully or partially non-inlined code based
> on optimisation and code analysis - I'm talking about the logical
> handling of the code, not the details of the code generation.) The
> compiler could still use a non-inlined version of my static definition -
> I usually have "-Winline" in effect with gcc, which will warn me if it
> does. And in important cases, I use gcc's "always_inline" attribute,
> though of course that is not fully portable.
>
> So all my inline functions are "static inline". To me, "static inline"
> is more an indication of the programmer's intent and the meaning and use
> of the code - I think it is safe to say that any time I have used
> "inline", the specifier could be removed without actually changing the
> behaviour of the code.

The fact that you use -Winline, together with using inline with static
functions and other comments makes me think you use 'static inline' more
often in .c files than in header files; is it? If so, we agree on that.
If I use inline in a .c file, I certainly use 'static inline'. In
general, my rule is, similar to what I think I understood you do, use
static as I would do ignoring inline: that is, static goes to functions
in .c files.

The thing is, I rarely write inline functions in .c files, so most of my
inlines are non-static. I didn't mention that use of static inline for
that reason. But yes, it has its place in my code. :)


[...]

>>> - the kind of
>>> function previous generations might have written as function-like macros.
>>
>> For this, extern inline is best. Let me explain.
>>
>
> You are welcome to try to convince me :-)
>
> (Again - I can only say what is best for /me/, and not what is best for
> others.)
>

[...]

>
>>
>>>
>>> With "foo", you can have local modifiable static data.
>>
>> Local to what? In a header file?
>
> Local to the translation unit - just like in any other static function.

Okay, this seems to confirm. Yes, static inline in .c files is ok for
me :).

[...]

> Static data within a static inline function in a header could be useful
> in some cases - perhaps for a small memorization cache for a function -
> but I agree it would be rare. But static inline functions are not just
> for headers - they could be within a C file, and then access to static
> data (static to the file or to the function) is important. After all,
> all objects and functions within the C file should be static unless they
> have to be exported - there is no reason to have a non-static inline
> function in a C file.

Agree.

[...]

>
> The second version /is/ an external definition, which must be given in
> precisely one C file in the program. You don't necessarily need to
> write a body for it (indeed, if an inline version is visible then you
> are not allowed to write a second body). But you can, if you want,
> write a different function body. However, you still need that external
> definition, easy though it may be.

Yeah; that's the kind of thing I would expect libc to do. Provide an
asm version for the extern version, and then provide inline C versions
of the same functions. Except that libc really uses GNU inline, and
the inline versions are provided by GCC instead of glibc.

[...]

> I guess we just have different opinions here, and that's fine. I'm sure
> there are many differences in our styles and habits. Some differences
> will have clear justifications based on the kinds of coding we do, and
> the different balances of the pros and cons of different choices.
> Others will be habits, or preferences, or relatively minor issues that
> could work in many ways.

:)

Cheers,
Alex