Re: [avr-libc-dev] [RFC] make #includes consistent

[Joerg Wunsch]

As Theodore A. Roth wrote:

> This patch makes the headers in include/avr #include files from
> <avr/*.h> to be consistent with what the user should be doing.

> Does this look like a sane thing to do? I won't commit this one
> unless I get some positive feed back.

Looks OK to me.

> Would there be any objections to sticking #warning messages in the files in 
> include/ which just redirect down into include/avr/ ? The messages would 
> just say something like:
> 
>   #warning "Deprecated: you should #include <avr/foo.h> instead"

Please do.  FreeBSD is doing that with some pre-ANSI C header files
(like <malloc.h>), and you won't believe how much inappropriate header
file usage in `random Internet C code' is uncovered by this.

> I just noticed that there are some source files which include the following 
> files:
> 
>   stdio.h
>   limits.h
>   sys/types.h
>   stddef.h
>   sys/systemcfg.h

Curious: which source files?

> Should we even be #include'ing these? Should we supply our own
> versions which trump the gcc supplied files?

Isn't gcc only installing `fixincluded' header files from the system?

Since the hosting system's header files ar meaningless to the AVR
target, it probably shouldn't install any of them at all.

However, what already made me curious (and those headers seem to shed
some light on this) is that some of our header files #define
__need_somefoo, where it's obviously up to gcc to decode this.
(somefoo = {NULL, size_t, wchar_t}).

ISO C mandates that <stddef.h> defines the following symbols:

ptrdiff_t - signed result of subtracting two pointers
size_t - usigned integer result of sizeof operator
wchar_t - integer type covering the largest character set
NULL - null pointer constant
offsetof() - offset of a struct member in bytes

So we should indeed have an <stddef.h> since it makes sense.

Shipping <sys/types.h> might make some sense, too, for compatibility
with Unix implementations.

Shipping <stdio.h> doesn't make any sense to me, as long as there are
no library functions that could be declared in that file (like
sprintf() perhaps).

<limits.h> would probably make sense, too.

-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/