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

[Theodore A. Roth]

On Thu, 30 Sep 2004, 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 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?

No. The inline functions _must_ be defined in the headers if they are
public interfaces. Private interfaces within a single C module don't
need to be in headers, but that is something other than what we are
discussing.

If a function is already compiled into a function in the library, then
how is it going to be inlined in your code?

You are still confusing a header and a C module. Think about how a macro
or an inline function is used and it should be less confusing.

> 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).

If you define the inline function in a header and include the header in
_your_ module, then it is specific the the arch you selected when
building your module. libc.a never comes into play in that case.

> And there is the issue of whether to use "inline" or "__inline__".

If it is defined in avr-libc provided header, we should be using
__inline__. I thought that was fairly clear in the link I posted:

  (If you are writing a header file to be included in ISO C programs,
  write __inline__ instead of inline. See Alternate Keywords.)

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

Actually, one thing I kinda like about inline functions is the fact the
they are so much easier to read than big nasty macros. In most cases,
easier to read implies easier to validate against bugs.

---
Ted Roth
PGP Key ID: 0x18F846E9
Jabber ID: address@hidden