[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