os-test > fnmatch

Legend

Good. A cell is good if the declaration is present in the header and can be linked with libc. This outcome means the test succeeded with the appropriate -D_POSIX_C_SOURCE=202405 or -D_XOPEN_SOURCE=800 feature macros and the standard libraries libc, libpthread, libm, librt, and libxnet.

Missing optional. A cell is missing_optional if the test could not be compiled, but the declaration is optional in POSIX and need not be provided.

Outside libc. A cell is outside_libc if the test could be compiled, but had to be linked with another standard library than the ones prescribed by POSIX: libc, libpthread, libm, librt, and libxnet. This may not conform to POSIX depending on the linking options provided by getconf(1)/confstr(3).

Extension. A cell is extension if the test could not be compiled with the _POSIX_C_SOURCE and _XOPEN_SOURCE feature macros, but it could instead be compiled with other system-specific feature macros that provide the entire API. This outcome means the system header feature macro logic does not support the latest POSIX.1-2024 standard and only receives partial credit. This outcome typically indicates a declaration new to POSIX.1-2024.

Previous posix. A cell is previous_posix if the test could not be compiled with the -D_POSIX_C_SOURCE=202405 or -D_XOPEN_SOURCE=800 feature macros from the POSIX.1-2024 standard, but the test could instead be compiled with the older -D_POSIX_C_SOURCE=200809L or -D_XOPEN_SOURCE=700 feature macros from the older POSIX.1-2008 standard. This outcome means the system header feature macro logic does not support the latest POSIX.1-2024 standard and only receives partial credit. In particular, the header did not check if the value was higher than the supported value, but instead hard-coded the supported values, and failed to be forward compatible with new standard versions.

None. A cell is none if there is no test data result for that operating system.

Compile error. A cell is compile_error if the test could not be compiled and the error message was not recognized as a more precise error test outcome.

Incompatible. A cell is incompatible if the declaration existed in the header, but had a signature that is incompatible with the standardized declaration. This outcome typically indicates a type error in the declaration. Addressing the issue may require an incompatible ABI change or special compatibility logic.

Missing header. A cell is missing_header if the header did not exist.

Undeclared. A cell is undeclared if the header did not contain the declaration.

Undefined reference. A cell is undefined if the test could be compiled, but could not be linked with the standard library.

Unknown type. A cell is unknown_type if the test could not be compiled and failed because a required type was not declared. In some cases, functions fail because the header omitted a required type for a function and instead declared the function in an alternate fashion with an incompatible alias for the type.

§. The § link on the left of each row links to that row.

fnmatch

This suite tests fnmatch.

Each feature in the POSIX fnmatch pattern syntax is tested.

This suite is split into the strict base POSIX tests, which tests every sentence that is mandatory in POSIX; and the nonstandard tests, which tests all the optional behavior as well as common de facto extensions.

Each fnmatch feature is exhaustively combined with each other fnmatch feature to ensure that the features work together. More complicated tests combine multiple features in interesting cases. Each flag to fnmatch is tested as well with the relevant features.

The POSIX requirements on fnmatch can be tricky to understand. The POSIX.1-2024 chapter 2.14 text could not be written to be more confusing, as well as the relevant implications on the chapter 9 bracket expression syntax that is shared with regular expressions, but with additional special rules. Many tests use a truth table approach where every possible reasonable input is given to each pattern, so it's more likely that implementation bugs are discovered.

This suite has resolved the proper behaviors of as many unthinkably weird edge cases as possible. The backslash escaping rules have been an endless ride of curious questions about what happens if you put backslashes in unexpected places like [[:al\num:]], which the standard fails to consider explicitly, and we have to interpret what other language does apply to this case. POSIX.1-2024 changed a lot of the relevant language compared to the older POSIX.1-2008 in an effort to fix contradictions, and the resulting prose is endlessly difficult to interpret, and requires the rationale section to figure out what heck they even meant. Some patterns have unspecified behavior and are not tested.

The nonstandard tests check every extension I know of, along with UTF-8 and unicode support, including case sensitivity and the behavior on invalid UTF-8 sequences. It's technically fine to disagree with the nonstandard tests, and they mostly exist to study the availability of extensions, and to make sure they are implemented properly in a common way. There are very few extensions to the fnmatch pattern format, since POSIX is very strict unlike regular expressions, but POSIX does allow a few extensions like [^ behaving the same as [^.

Overall this test suite is very comprehensive and should provide a near exhaustive coverage of the fnmatch features. I read every relevant sentence in POSIX and made sure a test case covered each sentence.