Re: any plans for an "official" newlib snapshot ?

["J. Johnston" <jjohnstn at cygnus dot com>]

Werner Almesberger wrote:
> 
> J. Johnston wrote:
> > The general newlib goal is ANSI C compliance (not necessarily full-function)
> > and a reasonable set of POSIX / Unix extensions.
> 
> Perfect ;-)
> 
> > Yes, that was what I was thinking.
> 
> Great, so let's start then. There's one major compatibility problem I
> haven't fixed yet:
>  - libc/include/sys/unistd.h defines MAXNAMLEN as 1024
>  - on Linux, d_name in struct dirent is 256 bytes long
> 
> Right now, I define the right MAXNAMLEN in libc/sys/linux/sys/dirent.h,
> so depending on what you include first, you get the correct value or
> not. (libc/sys/sparc64/sys/dirent.h seems to fight with similar issues.
> sun4 and decstation just have a plain #define. Not sure how well they
> compile ...)
> 
> The easiest solution would be remove the #define from
> libc/include/sys/unistd.h and to add the following to libc/include/dirent.h
> 
> #if !defined(MAXNAMLEN) && !defined(_POSIX_SOURCE)
> #define MAXNAMLEN 1024
> #endif
> 
> after including sys/dirent.h. That way, sys/dirent.h can reliably
> provide the correct value.
> 
> But I'm not sure if this is compatible with wherever that MAXNAMLEN
> appeared originally. (BTW, glibc 2.1.3 also defines it in dirent.h, not
> unistd.h)
> 
> Comments ?
> 

This is fine as long as the file libc/posix/execvp.c is changed to
include dirent.h (it uses MAXNAMLEN but only includes unistd.h).
Everywhere else where MAXNAMLEN is covered by an include of dirent.h.

Care to put together a patch?

-- Jeff J.