10 #
11
12 #
13 # Copyright 2015 Garrett D'Amore <garrett@damore.org>
14 #
15
16 The configuration files in this directory are structured using the
17 syntax defined in the ../README file. They make use of the compilation
18 environments declared in ../compilation.cfg, and are processed by the
19 symbols test.
20
21 We have organized the files by header file, that is the tests for symbols
22 declared in a header file (e.g. <unistd.h> appear in a file based on that
23 header file's name (e.g. unistd_h.cfg.) This is purely for convenience.
24
25 Within these various declarations, we have the following field types:
26
27 <envs> This is a list of compilation environments where the symbol
28 should be legal. To indicate that the symbol must not be legal
29 an environment group can be prefixed with "-". For example,
30 "SUS -SUSv4+" indicates a symbol that is legal in all SUS
31 environments up to SUSv3, and was removed in SUSv4 and subsequent
32 versions of SUS. As you can see, we can list multiple environments
33 or environment groups, and we can add or remove to previous groups
34 with subsequent ones.
35
36 <name> This is a symbol name. It follows the rules for C symbol names.
37
38 <header> This is a header file, for example, unistd.h. Conventionally,
39 the header files used should match the file where the test is
40 declared.
41
42 <type> This is a C type. Function types can be declared without their
43 names, e.g. "void (*)(int)". Structures (e.g. "struct stat") and
44 pointer types (e.g. "pthead_t *") are legal as well.
45
46 Here are the types of declarations in these files:
47
48 type | <name> | <header> | <envs>
49
50 Tests for a C type with <name>. The test verifies that a variable with
|
10 #
11
12 #
13 # Copyright 2015 Garrett D'Amore <garrett@damore.org>
14 #
15
16 The configuration files in this directory are structured using the
17 syntax defined in the ../README file. They make use of the compilation
18 environments declared in ../compilation.cfg, and are processed by the
19 symbols test.
20
21 We have organized the files by header file, that is the tests for symbols
22 declared in a header file (e.g. <unistd.h> appear in a file based on that
23 header file's name (e.g. unistd_h.cfg.) This is purely for convenience.
24
25 Within these various declarations, we have the following field types:
26
27 <envs> This is a list of compilation environments where the symbol
28 should be legal. To indicate that the symbol must not be legal
29 an environment group can be prefixed with "-". For example,
30 "SUS+ -SUSv4+" indicates a symbol that is legal in all SUS
31 environments up to SUSv3, and was removed in SUSv4 and subsequent
32 versions of SUS. As you can see, we can list multiple environments
33 or environment groups, and we can add or remove to previous groups
34 with subsequent ones.
35
36 <name> This is a symbol name. It follows the rules for C symbol names.
37
38 <header> This is a header file, for example, unistd.h. Conventionally,
39 the header files used should match the file where the test is
40 declared.
41
42 <type> This is a C type. Function types can be declared without their
43 names, e.g. "void (*)(int)". Structures (e.g. "struct stat") and
44 pointer types (e.g. "pthead_t *") are legal as well.
45
46 Here are the types of declarations in these files:
47
48 type | <name> | <header> | <envs>
49
50 Tests for a C type with <name>. The test verifies that a variable with
|