[avr-gcc-list] Re: [avr-libc-dev] RFD: more avr-libc API changes

[Wojtek Kaniewski]

Joerg Wunsch wrote:
> Would people find it annoying to add another subdir level?  So then,
> all "generic IO" headers could e.g. go into avr/generic/, the include
> statement would then be
>
> #include <avr/generic/uart.h>
>
> supposedly providing a generic uniform UART view for as many as
> possible AVRs.

Consequently, why not move <avr/io.h> to <avr/generic/io.h>? It's there 
to provide generic access to SFR's regardless of MCU used ;-)

> > That would be great. I wouldn't have to explain my friends what does
> > "PORTD&=~_BV(4);" mean (-;
>
> Except you'd need to explain them what cbi means as it's not a C
> standard, and could mean anything else beyond occasionally generating
> a CBI instruction. ;-)

They already knew what cbi() and sbi() did, without studying the whole C 
standard. When these macros suddenly disappeared after the upgrade of 
their favorite AVR development suite they had to get into details like 
bitwise operators. But I don't want to start another flamewar, it just 
would be nice if the macros were still somewhere around.

> Half point.  To compare it to my original complaint about the
> interrupt helpers, we didn't name one fdevopen() and the other one
> setup_stream_fdev().
>
> I found the underscores in the new names to improve readability, yet I
> wouldn't want to rename fdevopen() as it's an established interface.
> (fdevopen() has once been chosen as an analogy to fopen().)

Okay, I just wanted to point some future issues. If you're sure that 
these functions are called like they should be, it's fine.

Regards,
Wojtek