Sean Kelly e108928d21 * Modified all std modules to use core.sys.posix in place of std.c.linux. ... * Transformed std.c.linux.* into wrappers around core.sys.posix modules where appropriate. * Added std.c.osx as the OSX equivalent of std.c.linux. * Added std.c.osx.socket for OSX-specific socket declarations not covered by the Posix spec. * Altered all makefiles to zip, etc, the new std.c.osx package.		2009-03-26 03:02:32 +00:00
..
linux	* Modified all std modules to use core.sys.posix in place of std.c.linux.	2009-03-26 03:02:32 +00:00
osx	* Modified all std modules to use core.sys.posix in place of std.c.linux.	2009-03-26 03:02:32 +00:00
windows	rollup	2008-12-12 10:45:36 +00:00
fenv.d	The std.c modules now simply wrap the corresponding core.stdc modules to expose standard C declarations. std.c.os remains unchanged thus far, but will likely be altered as well. This unfortunately eliminates the auto doc generation for the std.c modules, since the modules are now largely empty. If the user wants to know what they contain, how the functions work, etc, I suggest for now simply referring to a C library spec--the core.stdc modules conform almost exactly to the C99 library definition.	2009-03-20 18:52:45 +00:00
locale.d	The std.c modules now simply wrap the corresponding core.stdc modules to expose standard C declarations. std.c.os remains unchanged thus far, but will likely be altered as well. This unfortunately eliminates the auto doc generation for the std.c modules, since the modules are now largely empty. If the user wants to know what they contain, how the functions work, etc, I suggest for now simply referring to a C library spec--the core.stdc modules conform almost exactly to the C99 library definition.	2009-03-20 18:52:45 +00:00
math.d	The std.c modules now simply wrap the corresponding core.stdc modules to expose standard C declarations. std.c.os remains unchanged thus far, but will likely be altered as well. This unfortunately eliminates the auto doc generation for the std.c modules, since the modules are now largely empty. If the user wants to know what they contain, how the functions work, etc, I suggest for now simply referring to a C library spec--the core.stdc modules conform almost exactly to the C99 library definition.	2009-03-20 18:52:45 +00:00
process.d	phobos 2.000	2007-09-10 06:45:08 +00:00
stdarg.d	The std.c modules now simply wrap the corresponding core.stdc modules to expose standard C declarations. std.c.os remains unchanged thus far, but will likely be altered as well. This unfortunately eliminates the auto doc generation for the std.c modules, since the modules are now largely empty. If the user wants to know what they contain, how the functions work, etc, I suggest for now simply referring to a C library spec--the core.stdc modules conform almost exactly to the C99 library definition.	2009-03-20 18:52:45 +00:00
stddef.d	The std.c modules now simply wrap the corresponding core.stdc modules to expose standard C declarations. std.c.os remains unchanged thus far, but will likely be altered as well. This unfortunately eliminates the auto doc generation for the std.c modules, since the modules are now largely empty. If the user wants to know what they contain, how the functions work, etc, I suggest for now simply referring to a C library spec--the core.stdc modules conform almost exactly to the C99 library definition.	2009-03-20 18:52:45 +00:00
stdio.d	The std.c modules now simply wrap the corresponding core.stdc modules to expose standard C declarations. std.c.os remains unchanged thus far, but will likely be altered as well. This unfortunately eliminates the auto doc generation for the std.c modules, since the modules are now largely empty. If the user wants to know what they contain, how the functions work, etc, I suggest for now simply referring to a C library spec--the core.stdc modules conform almost exactly to the C99 library definition.	2009-03-20 18:52:45 +00:00
stdlib.d	The std.c modules now simply wrap the corresponding core.stdc modules to expose standard C declarations. std.c.os remains unchanged thus far, but will likely be altered as well. This unfortunately eliminates the auto doc generation for the std.c modules, since the modules are now largely empty. If the user wants to know what they contain, how the functions work, etc, I suggest for now simply referring to a C library spec--the core.stdc modules conform almost exactly to the C99 library definition.	2009-03-20 18:52:45 +00:00
string.d	The std.c modules now simply wrap the corresponding core.stdc modules to expose standard C declarations. std.c.os remains unchanged thus far, but will likely be altered as well. This unfortunately eliminates the auto doc generation for the std.c modules, since the modules are now largely empty. If the user wants to know what they contain, how the functions work, etc, I suggest for now simply referring to a C library spec--the core.stdc modules conform almost exactly to the C99 library definition.	2009-03-20 18:52:45 +00:00
time.d	The std.c modules now simply wrap the corresponding core.stdc modules to expose standard C declarations. std.c.os remains unchanged thus far, but will likely be altered as well. This unfortunately eliminates the auto doc generation for the std.c modules, since the modules are now largely empty. If the user wants to know what they contain, how the functions work, etc, I suggest for now simply referring to a C library spec--the core.stdc modules conform almost exactly to the C99 library definition.	2009-03-20 18:52:45 +00:00
wcharh.d	The std.c modules now simply wrap the corresponding core.stdc modules to expose standard C declarations. std.c.os remains unchanged thus far, but will likely be altered as well. This unfortunately eliminates the auto doc generation for the std.c modules, since the modules are now largely empty. If the user wants to know what they contain, how the functions work, etc, I suggest for now simply referring to a C library spec--the core.stdc modules conform almost exactly to the C99 library definition.	2009-03-20 18:52:45 +00:00