Discussion: Replace function-like macros by inline functions?

[BenBE]

While working my way through several headers I noticed quite a few #defines that better should be inline functions.

This suggestion does not cover the various cast helpers, but things like e.g. Settings_cpuId or xSnprintf.

Detecting support for LTO in configure.ac we even could implement all those function outside the header files without loosing any performance.

[cgzones]

Me preference is also using type-safe (inline) function than macros (except generic types, like in MAXIMUM, are needed or the code location should not change, e.g. __FILE__ for debugging).
The second point affects xSnprintf, when implemented like in #115.

[BenBE]

Regarding xSnprintf I just noticed that the macro is duplicated in both XAlloc.h and XAlloc.c. Patch to remove the duplication incoming.

Also just noted a grave bug in the xSnprintf macro definition (addressed in #155) …

[cgzones]

Considering the function String_startsWith() from StringUtils.h I see four ways to implement it:

I (preprocessor macro)
StringUtils.h:

#define String_startsWith(s, match) (strncmp((s),(match),strlen(match)) == 0)

II (header inline function)
StringUtils.h:

static inline bool String_startsWith(const char *s, const char *match) {
    return strncmp(s, match, strlen(match)) == 0;
}

III (external inline function)
StringUtils.h:

bool String_startsWith(const char *s, const char *match);

StringUtils.c:

extern inline bool String_startsWith(const char *s, const char *match) {
    return strncmp(s, match, strlen(match)) == 0;
}

IV (normal function)
StringUtils.h:

bool String_startsWith(const char *s, const char *match);

StringUtils.c:

bool String_startsWith(const char *s, const char *match) {
    return strncmp(s, match, strlen(match)) == 0;
}

Option	type safe	inlined by default	issues
I	no	yes	the usage of String_startsWith() requires an include of StringUtils.h and <string.h> for strncmp()
II	yes	yes	-
III	yes	yes	a extern inline function can not call any static function, cause the file-local static function is not visible in the calling translation unit
IV	yes	no (requires LTO/IPO)	-

My personal preference is a mix of II and IV, using II for simple functions up to 3 lines.

[BenBE]

I'd prefer IV or II. Not sure about the semantics of III* though. And I should be avoided due to type safety issues.

*The gist I got from looking it up seems like an invitation to yourself for a hell lot of linking issues …

[cgzones]

Mentioned in https://github.com/htop-dev/htop/blob/master/docs/styleguide.md#symbol-exports