|
1 |
| -// |
2 |
| -// We consider the following specs reasonably normative with respect |
3 |
| -// to interoperating with the C standard library (libc/msvcrt): |
4 |
| -// |
5 |
| -// - ISO 9899:1990 ('C95', 'ANSI C', 'Standard C'), NA1, 1995. |
6 |
| -// - ISO 9899:1999 ('C99' or 'C9x'). |
7 |
| -// - ISO 9945:1988 / IEEE 1003.1-1988 ('POSIX.1'). |
8 |
| -// - ISO 9945:2001 / IEEE 1003.1-2001 ('POSIX:2001', 'SUSv3'). |
9 |
| -// - ISO 9945:2008 / IEEE 1003.1-2008 ('POSIX:2008', 'SUSv4'). |
10 |
| -// |
11 |
| -// Despite having several names each, these are *reasonably* coherent |
12 |
| -// point-in-time, list-of-definition sorts of specs. You can get each under a |
13 |
| -// variety of names but will wind up with the same definition in each case. |
14 |
| -// |
15 |
| -// Our interface to these libraries is complicated by the non-universality of |
16 |
| -// conformance to any of them. About the only thing universally supported is |
17 |
| -// the first (C95), beyond that definitions quickly become absent on various |
18 |
| -// platforms. |
19 |
| -// |
20 |
| -// We therefore wind up dividing our module-space up (mostly for the sake of |
21 |
| -// sanity while editing, filling-in-details and eliminating duplication) into |
22 |
| -// definitions common-to-all (held in modules named c95, c99, posix88, posix01 |
23 |
| -// and posix08) and definitions that appear only on *some* platforms (named |
24 |
| -// 'extra'). This would be things like significant OSX foundation kit, or |
25 |
| -// win32 library kernel32.dll, or various fancy glibc, linux or BSD |
26 |
| -// extensions. |
27 |
| -// |
28 |
| -// In addition to the per-platform 'extra' modules, we define a module of |
29 |
| -// "common BSD" libc routines that never quite made it into POSIX but show up |
30 |
| -// in multiple derived systems. This is the 4.4BSD r2 / 1995 release, the |
31 |
| -// final one from Berkeley after the lawsuits died down and the CSRG |
32 |
| -// dissolved. |
33 |
| -// |
| 1 | +#[doc = " |
| 2 | +Bindings for libc. |
| 3 | +
|
| 4 | +We consider the following specs reasonably normative with respect |
| 5 | +to interoperating with the C standard library (libc/msvcrt): |
| 6 | +
|
| 7 | +* ISO 9899:1990 ('C95', 'ANSI C', 'Standard C'), NA1, 1995. |
| 8 | +* ISO 9899:1999 ('C99' or 'C9x'). |
| 9 | +* ISO 9945:1988 / IEEE 1003.1-1988 ('POSIX.1'). |
| 10 | +* ISO 9945:2001 / IEEE 1003.1-2001 ('POSIX:2001', 'SUSv3'). |
| 11 | +* ISO 9945:2008 / IEEE 1003.1-2008 ('POSIX:2008', 'SUSv4'). |
| 12 | +
|
| 13 | +Despite having several names each, these are *reasonably* coherent |
| 14 | +point-in-time, list-of-definition sorts of specs. You can get each under a |
| 15 | +variety of names but will wind up with the same definition in each case. |
| 16 | +
|
| 17 | +Our interface to these libraries is complicated by the non-universality of |
| 18 | +conformance to any of them. About the only thing universally supported is |
| 19 | +the first (C95), beyond that definitions quickly become absent on various |
| 20 | +platforms. |
| 21 | +
|
| 22 | +We therefore wind up dividing our module-space up (mostly for the sake of |
| 23 | +sanity while editing, filling-in-details and eliminating duplication) into |
| 24 | +definitions common-to-all (held in modules named c95, c99, posix88, posix01 |
| 25 | +and posix08) and definitions that appear only on *some* platforms (named |
| 26 | +'extra'). This would be things like significant OSX foundation kit, or |
| 27 | +win32 library kernel32.dll, or various fancy glibc, linux or BSD |
| 28 | +extensions. |
| 29 | +
|
| 30 | +In addition to the per-platform 'extra' modules, we define a module of |
| 31 | +'common BSD' libc routines that never quite made it into POSIX but show up |
| 32 | +in multiple derived systems. This is the 4.4BSD r2 / 1995 release, the |
| 33 | +final one from Berkeley after the lawsuits died down and the CSRG |
| 34 | +dissolved. |
| 35 | +"]; |
34 | 36 |
|
35 | 37 | // Initial glob-exports mean that all the contents of all the modules
|
36 | 38 | // wind up exported, if you're interested in writing platform-specific code.
|
|
0 commit comments