Name |
Date |
Size |
#Lines |
LOC |
||
---|---|---|---|---|---|---|
.. | - | - | ||||
aarch64/ | H | - | - | 4,093 | 2,672 | |
arm/ | H | - | - | 2,220 | 1,710 | |
bench/ | H | - | - | 685 | 549 | |
include/ | H | - | - | 137 | 106 | |
test/ | H | - | - | 2,372 | 1,962 | |
x86_64/ | H | - | - | 11 | 3 | |
Dir.mk | H A D | 10-Jan-2025 | 3.2 KiB | 119 | 88 | |
README.contributors | H A D | 09-Jun-2023 | 1.2 KiB | 31 | 22 |
README.contributors
1STYLE REQUIREMENTS 2================== 3 41. Most code in this sub-directory is expected to be upstreamed into glibc so 5 the GNU Coding Standard and glibc specific conventions should be followed 6 to ease upstreaming. 7 82. ABI and symbols: the code should be written so it is suitable for inclusion 9 into a libc with minimal changes. This e.g. means that internal symbols 10 should be hidden and in the implementation reserved namespace according to 11 ISO C and POSIX rules. If possible the built shared libraries and static 12 library archives should be usable to override libc symbols at link time (or 13 at runtime via LD_PRELOAD). This requires the symbols to follow the glibc ABI 14 (other than symbol versioning), this cannot be done reliably for static 15 linking so this is a best effort requirement. 16 173. API: include headers should be suitable for benchmarking and testing code 18 and should not conflict with libc headers. 19 20 21CONTRIBUTION GUIDELINES FOR string SUB-DIRECTORY 22================================================ 231. Code: 24 - The assumptions of the code must be clearly documented. 25 26 - Assembly style should be consistent across different implementations. 27 28 292. Performance: 30 - Benchmarking is needed on several microarchitectures. 31