Walter Bright cf644a325a add shared		2009-05-08 05:00:12 +00:00
..
linux	add shared	2009-05-08 05:00:12 +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	Resolved differences between Posix and Windows declarations for BSD socket routines by standardizing on the Posix declaration (which is likely the correct one). This required reverting some changes to std.socket and changing the type of SOCKET from uint to int, which shoudl be fine since they're both 4 bytes anyway.	2009-03-26 18:04:44 +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	add shared	2009-05-08 05:00:12 +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