RE: [avr-libc-dev] [RFC] New eeprom.h

[Weddington, Eric]

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> org] On Behalf Of David Brown
> Sent: Wednesday, January 16, 2008 12:34 PM
> To: address@hidden
> Subject: Re: [avr-libc-dev] [RFC] New eeprom.h
> 
> Weddington, Eric wrote:
> >  
> > 
> >> -----Original Message-----
> >> From: 
> >> address@hidden 
> >> [mailto:address@hidden
> >> org] On Behalf Of David Brown
> >> Sent: Wednesday, January 16, 2008 10:01 AM
> >> To: address@hidden
> >> Subject: Re: [avr-libc-dev] [RFC] New eeprom.h
> >>
> >> Weddington, Eric wrote:
> >>>  
> >>>

> The current eeprom.h file from the latest winavr package uses static 
> inline functions in exactly this way, unless I'm really 
> getting things 
> mixed up.

Point.

Personally, I've just never been fond of the idea of putting function
definitions in header files.

 
> > - The inline portion wouldn't work because we now have 
> object code, and
> > the linking stage (AFAIK) doesn't do inlining.
> 
> It does not *yet* do inlining in this way.

But I have to deal with today, not the future.


> Is a multi-lib avrlibc something that is being considered?  I can see 
> that there would be definite advantages, but I can also see 
> it being a 
> lot more work.

We have a task in the project Task List for it, but as you said, it's a
lot more work and no one has had the time or inclination to tackle it.

Eric W.