No prototype for readdir_r

[Craig Howland]

On 11/15/2013 01:49 PM, Joel Sherrill wrote:
> Hi
>
> I noticed that readdir_r() does not have a prototype.
> It should be in dirent.h. I am happy to add it to
> the RTEMS dirent.h but there are other versions of
> this file and
>
> ./libc/include/sys/dirent.h
> ./libc/include/dirent.h
> ./libc/machine/spu/sys/dirent.h
> ./libc/sys/rtems/sys/dirent.h
> ./libc/sys/decstation/sys/dirent.h
> ./libc/sys/sun4/sys/dirent.h
> ./libc/sys/linux/bits/dirent.h
> ./libc/sys/linux/sys/dirent.h
> ./libc/sys/sparc64/sys/dirent.h
> ./libc/sys/sysvi386/sys/dirent.h
>
> I can drop the prototype in those at the same time.
>
> And ... Linux man page shows these guards. What should
> they be on newlib?
>
>      _POSIX_C_SOURCE >= 1 || _XOPEN_SOURCE || _BSD_SOURCE ||
>      _SVID_SOURCE || _POSIX_SOURCE
>
      It probably is not worth bothering with a guard.
      dirent.h is not in the C standard, so there is no gate needed based on 
it.  (Someone could say that with your sample gate that it would be skipped with 
STRICT_ANSI, but from that point of view, dirent.h should not even be included.)
      POSIX says is was added in issue 2, which is so ancient that it seems 
unreasonable to add something now to avoid it for someone trying to use issue 
1.  (I think that the guard would probably be _POSIX_C_SOURCE >= 199209 to be 
for issue 2, assuming that sys/cdefs.h has been included before the check.)  I 
don't know why GLIBC's test is for 1, instead of 2.
      Craig