Re: [avr-libc-dev] [patch] remove deprecated files.

[Joerg Wunsch]

As E. Weddington wrote:

> Can I get a ruling on what should be done with BV() and _BV()?
> 
> IIRC, BV() is supposed to be deprecated.
> IIRC, anything with an underscore (such as _BV()) is supposed to be reserved 
> for the implementation. I know that usage of _BV() has been promoted to users.

Well, `reserved for the implementation' means that _we_ (we are the
implementors) are the ones it's being reserved for. ;-)

While I didn't fully agree with Marek when he deprecated BV(), I can
at least partially understand his reasoning (in his opinion, BV was
much more likely to collide with something an application programmer
would like to use himself than most other of our names), and now that
it has been deprecated for a while, we should just continue removing
it.

OTOH, if we followed Marek's reasoning, we would eventually end up
prepending an underscore to almost any macro that is not defined by
one of the standards (C, or perhaps Posix).  I know that other AVR
compilers really do it that way, e. g. they use _SEI() where we use
sei(), but I'm not perfectly happy with that idea.  The way I'm
reading the standard, we are allowed to poiso^H^H^H^H^Hextend the name
space as long as the new names don't appear in the standard headers.
We are close to that, since most of our extensions are only declared/
defined in header files residing under the avr/ subdir.  Of course,
based on that, BV() would be perfectly OK, too, but see above, I
thought the issue was minor enough when we've been this discussing
with Marek last time, so let it be as it is now.

If we want to be politically clean, we could watch out our standard
headers for non-standard extensions, and hide them somehow behind
some magical #ifdef barriers.  That way, our compiler might become
fully standards-compliant some day. ;-)
-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/