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

[E. Weddington]

On 26 Apr 2004 at 22:34, Joerg Wunsch wrote:

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

Ok, so you don't fully agree on the deprecation but you understand the 
reasoning. But the standard says we can extend things, which is already being 
done elsewhere, so it makes sense that BV() would be ok too. Was there a 
determinate position on this issue in this? 

*sigh* I think I'll just leave it alone....... I never liked the name BV 
anyway.
 
> 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.  

And we should move a lot of things from <inttypes.h> to a new <stdint.h>, but 
that's a different topic.....

> That way, our compiler might become
> fully standards-compliant some day. ;-)

Feel free to volunteer to check for this.... ;-)