any plans for an "official" newlib snapshot ?

J. Johnston
Tue Nov 21 13:17:00 GMT 2000

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.

More information about the Newlib mailing list