Re: [avr-libc-dev] Can pgmspace.h __LPM_xxx__ macros become inlinefn's?

[Bill Somerville]

"E. Weddington" wrote:
> 
> Theodore A. Roth wrote:
> 
> >On Thu, 30 Sep 2004, E. Weddington wrote:
> >
> >
> >
> >>Hmm.
> >>All of the pgm_* API is implemented as #defines that eventually boil
> >>down to the __*LPM* style identifiers. Wouldn't declaring them as static
> >>make them non-visible outside of avr/pgmspace.h? I don't think this is
> >>desirable.
> >>
> >>
> >
> >No. You are confusing .h and .c files. The macro or inline func will be
> >visible to any file that #includes the header. Nothing changes in that
> >respect.
> >
> >Read what the gcc manual says about static and extern when used with an
> >inlined function:
> >
> >  http://gcc.gnu.org/onlinedocs/gcc-3.4.2/gcc/Inline.html#Inline
> >
> >
> >
> 
> Thanks Ted, and Geoffrey Wossum for the corrections, and thanks for the
> link Ted; it helped tremendously.
> 
> Unfortunately that section still seems to leave the issue a little clouded.

It is a bit muddy isn't it.

> 
> It doesn't say if use of "static inline" can be used with functions
> outside the module. It does say that use of "extern inline" can be used
> almost like a macro, including inlining the function in other modules.
> However, now these new __*LPM_* functions have to be implemented in .c
> files and rolled into the library, correct? And there are different
> functions for different architectures. Then there is the issue of
> whether we want these to be inlined even when no optimization is used
> (implying use of the always_inline attribute). And there is the issue of
> whether to use "inline" or "__inline__".

extern inline can be used to ensure that if a non-inline version is
generated then exactly one copy is generated in a library. For trivial
fn's like these that is not necessary and no library code needs to be
generated. If anyone is perverse enough to take the address of the fn in
multiple translation units then they deserve a bigger executable ;-)

No the inline functions will remain in the avr/pgmspace.h header file.

__inline__ is recommended in header files for now although with C99 it
is a genuine keyword and then it will be OK to use inline in headers as
is done in C++ already.

> 
> Wouldn't it be simpler to figure out what it is about the macros that
> -pedantic doesn't like?

The problem is that the used of a braced block in the middle of an
expression is not leagal C or C++. The block is required so that
automatic variables can be introduced for local storage (these are in
fact optimised away).

inline in C++ and now C99 was introduced to get around this problem
among others of which the most useful are the type safety of compiler
checked arguments etc, the avoidance of multiple evaluation of complex
arguments, and that the fn names are handled by the compiler which
honours C/C++ scoping rules unlike the CPP which doesn't.

> 
> Eric

Bill Somerville