Merge "Improve comment about glibc behavior difference." into main
diff --git a/tests/wchar_test.cpp b/tests/wchar_test.cpp
index c4cc0bd..5256b08 100644
--- a/tests/wchar_test.cpp
+++ b/tests/wchar_test.cpp
@@ -297,14 +297,20 @@
// mbrtowc returns 0 "if the next n or fewer bytes complete the multibyte
// character that corresponds to the null wide character"
//
- // mbrtoc says: "If s is not a null pointer, the mbtowc function either
- // returns 0 (if s points to the null character)..."
+ // mbrtoc (C23 7.24.7.2.4) says:
//
- // So mbrtowc will not provide the correct mbtowc return value for "" and
- // n = 0.
+ // If s is not a null pointer, the mbtowc function either returns 0 (if s
+ // points to the null character), or returns the number of bytes that are
+ // contained in the converted multibyte character (if the next n or fewer
+ // bytes form a valid multibyte character), or returns -1 (if they do not
+ // form a valid multibyte character).
//
- // glibc gets this right, but all the BSDs (including macOS) and bionic (by
- // way of openbsd) return -1 instead of 0.
+ // glibc's interpretation differs from all the BSDs (including macOS) and
+ // bionic (by way of openbsd). glibc returns 0 since s does point to the null
+ // character, whereas the BSDs return -1 because the next 0 bytes do not form
+ // a valid multibyte chatacter. glibc's interpretation is probably more
+ // correct from a strict interpretation of the spec, but considering the other
+ // APIs behave more like the BSD interpretation that may be a bug in the spec.
#ifdef __GLIBC__
int expected_result_for_zero_length_empty_string = 0;
#else