How to inline non-exported functions in library?

[Ian]

Peace, language lawyers!

I'm developing a (static) library for a "memory-challenged"
platform (ie, mobile).

I want to (force the compiler to) inline some functions -- that
are not meant to be exported to the library's clients.

Example:

file1.c:
// Exported.
public_foo( void ); // Calls my_bar() and common_bar().

// Private.
static INLINE my_bar( void ); // Only called by functions in
this translation unit.
INLINE common_bar( void ); // May be called from other
translation units, too.

file2.c:
// Exported.
public_another_foo( void ); // Calls common_bar().

Currently, to inline and prevent exporting, I #include a file with
the static INLINE function.

This is not _standard_ C, but most compilers do provide some
"inline" keyword as a language extension.

Questions:

1. Is there a readable, manageable, semi-portable way to inline
functions in a library?

2. Your experience with compilers (especially GCC, VC, ARM's,
TI's): will they allow inlining, especially of non-static
functions, when building a library?

)

 

[Richard Bos]

I want to (force the compiler to) inline some functions -- that
are not meant to be exported to the library's clients.

Example:

file1.c:
// Exported.
public_foo( void ); // Calls my_bar() and common_bar().

// Private.
static INLINE my_bar( void ); // Only called by functions in
this translation unit.
INLINE common_bar( void ); // May be called from other

Currently, to inline and prevent exporting, I #include a file with
the static INLINE function.

This is not _standard_ C, but most compilers do provide some
"inline" keyword as a language extension.

Questions:

1. Is there a readable, manageable, semi-portable way to inline
functions in a library?

C99 provides the inline keyword. As you note, quite a few C89 compilers
do so as an extension, too. Apart from that, I don't know any way.

Richard

 

[Johan Borkhuis]

I'm developing a (static) library for a "memory-challenged"
platform (ie, mobile).

I want to (force the compiler to) inline some functions -- that
are not meant to be exported to the library's clients.

Currently, to inline and prevent exporting, I #include a file with
the static INLINE function.

This is not _standard_ C, but most compilers do provide some
"inline" keyword as a language extension.

Questions:

1. Is there a readable, manageable, semi-portable way to inline
functions in a library?

There are some other ways of doing this. You could remove the names from
your final object (using the strip command) or only include names that
you want to be included (see option --retain-symbols-file of the Gnu
linker). I don't know if this option is available for other linkers.
As you are working on a "memory challenged" device I think this would be
preferable over inline, as inline will include your code multiple times
in your final object.

Another way might be to use static functions instead of inline. This
might take some redesign, as you can only use static functions in the
scope of a module, but it would also get you the same result. The result
will be portable and will not rely on the use of the (non-standard for
pre-C99) inline keyword.

Kind regards,
Johan

--
o o o o o o o . . . _____J_o_h_a_n___B_o_r_k_h_u_i_s___
o _____ || http://www.borkhuis.com |
.][__n_n_|DD[ ====_____ | (e-mail address removed) |

>(________|__|_[_________]_|________________________________|

_/oo OOOOO oo` ooo ooo 'o!o!o o!o!o`
== VxWorks FAQ: http://www.xs4all.nl/~borkhuis/vxworks/vxworks.html ==

 

[Suman]

C99 provides the inline keyword.

... and, a word of caution.

Semantics
[...] Making a function an inline function suggests that calls to
the function be as fast as possible. The extent to which such
suggestions are effective is implementation-defined.