avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-libc-dev] [RFC] Solution for bug #3508


From: E. Weddington
Subject: Re: [avr-libc-dev] [RFC] Solution for bug #3508
Date: Fri, 13 Jun 2003 23:19:26 GMT

> As E. Weddington wrote:
> 
> > In thinking about a solution for bug #3508 
> > <http://savannah.nongnu.org/bugs/?
func=detailbug&bug_id=3508&group_id=2140>,
> >  the code in avr/interrupt.h that is the problem is:
> 
> > I propose a solution that does away with implementing 
this as an inline 
> > function, and implements it as a macro instead. 
> 
> I'd rather like to see that as another candidate for a 
compat/ subdir.
> Move it to <compat/interrupt.h>, and document it as 
deprecated.  These
> inline functions have been of close to zero practical 
value (in
> particular since you could not add or delete a single bit 
in the
> register, which is freuently needed).  By moving them out 
of the way,
> users of the 86RF401 device are no longer plagued with 
the problem,
> and those who really want to have their old functions 
could get them.
> 

Hmmm.....Ok, if we want to go down /that/ path: I agree in 
that the functions enable_external_int() and 
timer_enable_int() are ill-formed. 

I have ideas on a system to add useful functions in the 
future, but not until after 1.0

I'm certainly for deprecation of these 2 functions. I'd 
like more opinions about deprecation policy [and we can 
move this to the other thread].

Whether it's decided to:
1. Keep the deprecations in the original file until removal
2. Move the deprecations to a new, central file
I would still need to fix this as proposed because of the 
possibility of someone wanting to use both this processor 
and deprecated items, /unless/ this function was in it's 
own seperate, new file.

Opinions?

Eric
Weddington






reply via email to

[Prev in Thread] Current Thread [Next in Thread]