This one is blocking ​HaikuPorts Ticket #70, which affects building the CVS version of CVS. So until the libio.h functions are implemented we won't have a Haiku native CVS. Good news is that the BeOS CVS has been working ok as far as I can tell.

In that zip file the .OptionalPackageDescription said it was the BeOS version...
It's possible to build 1.12.13 with a bit of hacking along the way, which is what I'll probably do. But no use in sending in patches for that as the cvs version of cvs has dropped a lot of files some of which need to be patched on 1.12.13.
Andreas got it mosted working:
​http://ports.haiku-files.org/wiki/dev-util/cvs
I'll take another look at in the next few days here. But the cvs version of cvs is stuck util the functions actually exist.

libio.h is not a POSIX header, and the functionality doesn't seem to be standardized anywhere. If CVS is using it now for whatever reason (poor maintainer IMO), I would think we could easily live with an older version of it.

This one is blocking ​HaikuPorts Ticket #70, which affects building the CVS version of CVS. So until the libio.h functions are implemented we won't have a Haiku native CVS. Good news is that the BeOS CVS has been working ok as far as I can tell.

Futhermore, it would seem that stdarg.h and stddef.h are already part of GCC's included headers, and thus we do not provide separate versions of these (they should get installed into the appropriate gcc header directory when the development tools are added to the haiku image):

I just wanted to mention that several students for Google Code-in have taken on this task to complete. Depending on how things go, I'll post patches here for review prior to committing to trunk.

Great! Please take care not to add/change stuff that isn't actually supported by the implementation.

deangenovski, thanks, that's a start. scottmc and umccullough are right, though: Some headers don't define all the stuff required by POSIX themselves, but include other headers that do (which is just fine), and some headers are provided by the compiler. Moreover, POSIX requires dozens of headers of which Haiku is definitely missing quite a few, and likely has a good deal of headers that don't fully conform to the specification.

I think it would be best to organize the information either in a wiki or in hierarchical tickets. I.e. one overview section/ticket listing all the non-conforming/missing (and maybe even the conforming) headers, for each header a section/ticket listing the defects in the header, and per defect (or group of defects) a subsection/ticket detailing on them. As written earlier IMO the best approach is to compile a complete list of headers first and then iterate through them and add details. The second step can be parallelized wonderfully.

We've broken #4947 down into a few GCI tasks to have students research and provide a list of what's missing. From those results we will then open/update trac tickets to take on each of the missing parts. There's also some other tasks being worked on to implement some of the missing functions. A wiki checkoff list would be a good thing to add as well.

The list is largely incorrect. Haiku provides all of the functionality listed under <signal.h>, <sys/select.h>, <sys/stat.h>, <sys/times.h>, <time.h>, <unistd.h>. That's just what I can tell off the top of my head. I haven't checked the other stuff.