CVS commit: src/tests/lib/libc/locale

2023-11-27 Thread Christos Zoulas
Module Name:src
Committed By:   christos
Date:   Mon Nov 27 19:45:36 UTC 2023

Modified Files:
src/tests/lib/libc/locale: Makefile t_strfmon.c

Log Message:
Don't use fmtcheck for strfmon format strings. It does not work. Fix a broken
test.


To generate a diff of this commit:
cvs rdiff -u -r1.13 -r1.14 src/tests/lib/libc/locale/Makefile
cvs rdiff -u -r1.5 -r1.6 src/tests/lib/libc/locale/t_strfmon.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Modified files:

Index: src/tests/lib/libc/locale/Makefile
diff -u src/tests/lib/libc/locale/Makefile:1.13 src/tests/lib/libc/locale/Makefile:1.14
--- src/tests/lib/libc/locale/Makefile:1.13	Sun Jul 28 09:46:45 2019
+++ src/tests/lib/libc/locale/Makefile	Mon Nov 27 14:45:36 2023
@@ -1,4 +1,4 @@
-# $NetBSD: Makefile,v 1.13 2019/07/28 13:46:45 christos Exp $
+# $NetBSD: Makefile,v 1.14 2023/11/27 19:45:36 christos Exp $
 
 .include 
 
@@ -27,5 +27,6 @@ TESTS_C+=	t_strfmon
 COPTS.t_wctomb.c += -Wno-stack-protector
 COPTS.t_digittoint.c += -Wno-unused-variable
 COPTS.t_btowc.c += -Wno-unused-variable
+COPTS.t_strfmon.c += -Wno-format-nonliteral
 
 .include 

Index: src/tests/lib/libc/locale/t_strfmon.c
diff -u src/tests/lib/libc/locale/t_strfmon.c:1.5 src/tests/lib/libc/locale/t_strfmon.c:1.6
--- src/tests/lib/libc/locale/t_strfmon.c:1.5	Sat Oct 14 16:19:31 2023
+++ src/tests/lib/libc/locale/t_strfmon.c	Mon Nov 27 14:45:36 2023
@@ -1,4 +1,4 @@
-/* $NetBSD: t_strfmon.c,v 1.5 2023/10/14 20:19:31 christos Exp $ */
+/* $NetBSD: t_strfmon.c,v 1.6 2023/11/27 19:45:36 christos Exp $ */
 
 /*-
  * Copyright (c) 2017 The NetBSD Foundation, Inc.
@@ -31,7 +31,7 @@
  */
 
 #include 
-__RCSID("$NetBSD: t_strfmon.c,v 1.5 2023/10/14 20:19:31 christos Exp $");
+__RCSID("$NetBSD: t_strfmon.c,v 1.6 2023/11/27 19:45:36 christos Exp $");
 
 #include 
 #include 
@@ -52,7 +52,7 @@ ATF_TC_BODY(strfmon_locale, tc)
 		const char *locale;
 		const char *expected;
 	} tests[] = {
-	{ "C", "[ **1234.57] [ **1234.57]" },
+	{ "C", "[ **1234.57 ] [ **1234.57 ]" },
 	{ "de_DE.UTF-8", "[ **1234,57 €] [ **1.234,57 EUR]" },
 	{ "en_GB.UTF-8", "[ £**1234.57] [ GBP**1,234.57]" },
 	};
@@ -157,8 +157,7 @@ ATF_TC_BODY(strfmon_examples, tc)
 	for (i = 0; i < __arraycount(tests); ++i) {
 		snprintf(format, sizeof(format), "[%s] [%s] [%s]",
 		tests[i].format, tests[i].format, tests[i].format);
-		strfmon(actual, sizeof(actual) - 1,
-		fmtcheck(format, "%n %n %n"),
+		strfmon(actual, sizeof(actual) - 1, format,
 		123.45, -123.45, 3456.781);
 		ATF_CHECK_STREQ_MSG(tests[i].expected, actual,
 		"[%s]", tests[i].format);



CVS commit: src/tests/lib/libc/locale

2023-11-27 Thread Christos Zoulas
Module Name:src
Committed By:   christos
Date:   Mon Nov 27 19:45:36 UTC 2023

Modified Files:
src/tests/lib/libc/locale: Makefile t_strfmon.c

Log Message:
Don't use fmtcheck for strfmon format strings. It does not work. Fix a broken
test.


To generate a diff of this commit:
cvs rdiff -u -r1.13 -r1.14 src/tests/lib/libc/locale/Makefile
cvs rdiff -u -r1.5 -r1.6 src/tests/lib/libc/locale/t_strfmon.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.



CVS commit: src/tests/lib/libc/locale

2023-10-14 Thread Christos Zoulas
Module Name:src
Committed By:   christos
Date:   Sat Oct 14 20:19:31 UTC 2023

Modified Files:
src/tests/lib/libc/locale: t_strfmon.c

Log Message:
PR/57633: Jose Luis Duran: Add strfmon tests from FreeBSD


To generate a diff of this commit:
cvs rdiff -u -r1.4 -r1.5 src/tests/lib/libc/locale/t_strfmon.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Modified files:

Index: src/tests/lib/libc/locale/t_strfmon.c
diff -u src/tests/lib/libc/locale/t_strfmon.c:1.4 src/tests/lib/libc/locale/t_strfmon.c:1.5
--- src/tests/lib/libc/locale/t_strfmon.c:1.4	Thu Sep 28 09:31:11 2023
+++ src/tests/lib/libc/locale/t_strfmon.c	Sat Oct 14 16:19:31 2023
@@ -1,7 +1,8 @@
-/* $NetBSD: t_strfmon.c,v 1.4 2023/09/28 13:31:11 christos Exp $ */
+/* $NetBSD: t_strfmon.c,v 1.5 2023/10/14 20:19:31 christos Exp $ */
 
 /*-
  * Copyright (c) 2017 The NetBSD Foundation, Inc.
+ * Copyright (C) 2018 Conrad Meyer 
  * All rights reserved.
  *
  * This code is derived from software contributed to The NetBSD Foundation
@@ -30,9 +31,10 @@
  */
 
 #include 
-__RCSID("$NetBSD: t_strfmon.c,v 1.4 2023/09/28 13:31:11 christos Exp $");
+__RCSID("$NetBSD: t_strfmon.c,v 1.5 2023/10/14 20:19:31 christos Exp $");
 
 #include 
+#include 
 #include 
 #include 
 
@@ -83,11 +85,215 @@ ATF_TC_BODY(strfmon_pad, tc)
 ATF_REQUIRE_STREQ(string, "[ $123.45] [ $123.45]"); 
 }
 
+ATF_TC(strfmon_locale_thousands);
+
+ATF_TC_HEAD(strfmon_locale_thousands, tc)
+{
+	atf_tc_set_md_var(tc, "descr",
+	"Checks strfmon locale thousands separator");
+}
+
+ATF_TC_BODY(strfmon_locale_thousands, tc)
+{
+	char actual[40], expected[40];
+	struct lconv *lc;
+	const char *ts;
+	double n;
+
+	setlocale(LC_MONETARY, "sv_SE.UTF-8");
+
+	lc = localeconv();
+
+	ts = lc->mon_thousands_sep;
+	if (strlen(ts) == 0)
+		ts = lc->thousands_sep;
+
+	if (strlen(ts) < 2)
+		atf_tc_skip("multi-byte thousands-separator not found");
+
+	n = 1234.56;
+	strfmon(actual, sizeof(actual) - 1, "%i", n);
+
+	strcpy(expected, "1");
+	strlcat(expected, ts, sizeof(expected));
+	strlcat(expected, "234", sizeof(expected));
+
+	/* We're just testing the thousands separator, not all of strfmon. */
+	actual[strlen(expected)] = '\0';
+	ATF_CHECK_STREQ(expected, actual);
+}
+
+ATF_TC(strfmon_examples);
+ATF_TC_HEAD(strfmon_examples, tc) {
+	atf_tc_set_md_var(tc, "descr",
+	"Checks strfmon field formats");
+}
+
+ATF_TC_BODY(strfmon_examples, tc)
+{
+	const struct {
+		const char *format;
+		const char *expected;
+	} tests[] = {
+	{ "%n", "[$123.45] [-$123.45] [$3,456.78]" },
+	{ "%11n", "[$123.45] [   -$123.45] [  $3,456.78]" },
+	{ "%#5n", "[ $   123.45] [-$   123.45] [ $ 3,456.78]" },
+	{ "%=*#5n", "[ $***123.45] [-$***123.45] [ $*3,456.78]" },
+	{ "%=0#5n", "[ $000123.45] [-$000123.45] [ $03,456.78]" },
+	{ "%^#5n", "[ $  123.45] [-$  123.45] [ $ 3456.78]" },
+	{ "%^#5.0n", "[ $  123] [-$  123] [ $ 3457]" },
+	{ "%^#5.4n", "[ $  123.4500] [-$  123.4500] [ $ 3456.7810]" },
+	{ "%(#5n", "[ $   123.45 ] [($   123.45)] [ $ 3,456.78 ]" },
+	{ "%!(#5n", "[123.45 ] [(   123.45)] [  3,456.78 ]" },
+	{ "%-14#5.4n", "[ $   123.4500 ] [-$   123.4500 ] [ $ 3,456.7810 ]" },
+	{ "%14#5.4n", "[  $   123.4500] [ -$   123.4500] [  $ 3,456.7810]" },
+	};
+	size_t i;
+	char actual[100], format[50];
+
+	if (setlocale(LC_MONETARY, "en_US.UTF-8") == NULL)
+		atf_tc_skip("unable to setlocale()");
+
+	for (i = 0; i < __arraycount(tests); ++i) {
+		snprintf(format, sizeof(format), "[%s] [%s] [%s]",
+		tests[i].format, tests[i].format, tests[i].format);
+		strfmon(actual, sizeof(actual) - 1,
+		fmtcheck(format, "%n %n %n"),
+		123.45, -123.45, 3456.781);
+		ATF_CHECK_STREQ_MSG(tests[i].expected, actual,
+		"[%s]", tests[i].format);
+	}
+}
+
+ATF_TC(strfmon_cs_precedes_0);
+
+ATF_TC_HEAD(strfmon_cs_precedes_0, tc)
+{
+	atf_tc_set_md_var(tc, "descr",
+	"sep_by_space x sign_posn when cs_precedes = 0");
+}
+
+ATF_TC_BODY(strfmon_cs_precedes_0, tc)
+{
+	const struct {
+		const char *expected;
+	} tests[] = {
+	/* sep_by_space x sign_posn */
+	{ "[(123.00$)] [-123.00$] [123.00$-] [123.00-$] [123.00$-]" },
+	{ "[(123.00 $)] [-123.00 $] [123.00 $-] [123.00 -$] [123.00 $-]" },
+	{ "[(123.00$)] [- 123.00$] [123.00$ -] [123.00- $] [123.00$ -]" },
+	};
+	size_t i, j;
+	struct lconv *lc;
+	char actual[100], buf[100];
+
+	if (setlocale(LC_MONETARY, "en_US.UTF-8") == NULL)
+		atf_tc_skip("unable to setlocale()");
+
+	lc = localeconv();
+	lc->n_cs_precedes = 0;
+
+	for (i = 0; i < __arraycount(tests); ++i) {
+		actual[0] = '\0';
+		lc->n_sep_by_space = i;
+
+		for (j = 0; j < 5; ++j) {
+			lc->n_sign_posn = j;
+
+			strfmon(buf, sizeof(buf) - 1, "[%n] ", -123.0);
+			strlcat(actual, buf, sizeof(actual));
+		}
+
+		actual[strlen(actual) - 1] = '\0';
+		ATF_CHECK_STREQ_MSG(tests[i].expected, actual,
+		"sep_by_space = %zu", i);
+	}
+}
+

CVS commit: src/tests/lib/libc/locale

2023-10-14 Thread Christos Zoulas
Module Name:src
Committed By:   christos
Date:   Sat Oct 14 20:19:31 UTC 2023

Modified Files:
src/tests/lib/libc/locale: t_strfmon.c

Log Message:
PR/57633: Jose Luis Duran: Add strfmon tests from FreeBSD


To generate a diff of this commit:
cvs rdiff -u -r1.4 -r1.5 src/tests/lib/libc/locale/t_strfmon.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.



CVS commit: src/tests/lib/libc/locale

2023-09-28 Thread Christos Zoulas
Module Name:src
Committed By:   christos
Date:   Thu Sep 28 13:31:11 UTC 2023

Modified Files:
src/tests/lib/libc/locale: t_strfmon.c

Log Message:
Add testing for pad resetting (Jose Luis Duran)


To generate a diff of this commit:
cvs rdiff -u -r1.3 -r1.4 src/tests/lib/libc/locale/t_strfmon.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Modified files:

Index: src/tests/lib/libc/locale/t_strfmon.c
diff -u src/tests/lib/libc/locale/t_strfmon.c:1.3 src/tests/lib/libc/locale/t_strfmon.c:1.4
--- src/tests/lib/libc/locale/t_strfmon.c:1.3	Mon Aug  2 13:41:07 2021
+++ src/tests/lib/libc/locale/t_strfmon.c	Thu Sep 28 09:31:11 2023
@@ -1,4 +1,4 @@
-/* $NetBSD: t_strfmon.c,v 1.3 2021/08/02 17:41:07 andvar Exp $ */
+/* $NetBSD: t_strfmon.c,v 1.4 2023/09/28 13:31:11 christos Exp $ */
 
 /*-
  * Copyright (c) 2017 The NetBSD Foundation, Inc.
@@ -30,21 +30,21 @@
  */
 
 #include 
-__RCSID("$NetBSD: t_strfmon.c,v 1.3 2021/08/02 17:41:07 andvar Exp $");
+__RCSID("$NetBSD: t_strfmon.c,v 1.4 2023/09/28 13:31:11 christos Exp $");
 
 #include 
 #include 
 #include 
 
-ATF_TC(strfmon);
+ATF_TC(strfmon_locale);
 
-ATF_TC_HEAD(strfmon, tc)
+ATF_TC_HEAD(strfmon_locale, tc)
 {
 	atf_tc_set_md_var(tc, "descr",
 		"Checks strfmon_l under different locales");
 }
 
-ATF_TC_BODY(strfmon, tc)
+ATF_TC_BODY(strfmon_locale, tc)
 {
 	const struct {
 		const char *locale;
@@ -67,10 +67,27 @@ ATF_TC_BODY(strfmon, tc)
 	}
 }
 
+ATF_TC(strfmon_pad);
+
+ATF_TC_HEAD(strfmon_pad, tc)
+{
+	atf_tc_set_md_var(tc, "descr", "Checks strfmon padding");
+}
+
+ATF_TC_BODY(strfmon_pad, tc)
+{
+char string[1024];
+
+ATF_REQUIRE(setlocale(LC_MONETARY, "en_US.UTF-8") != NULL);
+strfmon(string, sizeof(string), "[%8n] [%8n]", 123.45, 123.45);
+ATF_REQUIRE_STREQ(string, "[ $123.45] [ $123.45]"); 
+}
+
 ATF_TP_ADD_TCS(tp)
 {
 
-	ATF_TP_ADD_TC(tp, strfmon);
+	ATF_TP_ADD_TC(tp, strfmon_locale);
+	ATF_TP_ADD_TC(tp, strfmon_pad);
 
 	return atf_no_error();
 }



CVS commit: src/tests/lib/libc/locale

2023-09-28 Thread Christos Zoulas
Module Name:src
Committed By:   christos
Date:   Thu Sep 28 13:31:11 UTC 2023

Modified Files:
src/tests/lib/libc/locale: t_strfmon.c

Log Message:
Add testing for pad resetting (Jose Luis Duran)


To generate a diff of this commit:
cvs rdiff -u -r1.3 -r1.4 src/tests/lib/libc/locale/t_strfmon.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.



CVS commit: src/tests/lib/libc/locale

2022-12-21 Thread Thomas Klausner
Module Name:src
Committed By:   wiz
Date:   Wed Dec 21 09:33:35 UTC 2022

Modified Files:
src/tests/lib/libc/locale: t_mbstowcs.c

Log Message:
adapt mbstowcs_basic test for unicode table update

reformat so it's easier to find which result data belongs to which input


To generate a diff of this commit:
cvs rdiff -u -r1.2 -r1.3 src/tests/lib/libc/locale/t_mbstowcs.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Modified files:

Index: src/tests/lib/libc/locale/t_mbstowcs.c
diff -u src/tests/lib/libc/locale/t_mbstowcs.c:1.2 src/tests/lib/libc/locale/t_mbstowcs.c:1.3
--- src/tests/lib/libc/locale/t_mbstowcs.c:1.2	Wed Jul 12 17:32:51 2017
+++ src/tests/lib/libc/locale/t_mbstowcs.c	Wed Dec 21 09:33:34 2022
@@ -1,4 +1,4 @@
-/* $NetBSD: t_mbstowcs.c,v 1.2 2017/07/12 17:32:51 perseant Exp $ */
+/* $NetBSD: t_mbstowcs.c,v 1.3 2022/12/21 09:33:34 wiz Exp $ */
 
 /*-
  * Copyright (c) 2011 The NetBSD Foundation, Inc.
@@ -55,7 +55,7 @@
 #include 
 __COPYRIGHT("@(#) Copyright (c) 2011\
  The NetBSD Foundation, inc. All rights reserved.");
-__RCSID("$NetBSD: t_mbstowcs.c,v 1.2 2017/07/12 17:32:51 perseant Exp $");
+__RCSID("$NetBSD: t_mbstowcs.c,v 1.3 2022/12/21 09:33:34 wiz Exp $");
 
 #include 
 #include 
@@ -89,9 +89,10 @@ static struct test {
 		0x, 0x5D, 0x5B, 0x1, 0x1F, 0x5D, 0x5B, 0x20,
 		0x3FF, 0x5D, 0x5B, 0x400, 0x7FFF, 0x5D, 0x0A
 	},
-	{	 1, -1, -1,  1,  1, -1, -1,  1,  1, -1, -1,  1,  1, -1, -1,
-		 1,  1, -1, -1,  1,  1, -1, -1,  1, -1
-	}, 
+	{	 1, -1, -1, 1, 1, -1, 1, 1, 1, 1,
+		 -1, 1, 1, 1, -1, 1, 1, -1,
+		 -1, 1, 1, -1, -1, 1, -1
+	},
 	-1
 }, {
 	"ja_JP.ISO2022-JP",



CVS commit: src/tests/lib/libc/locale

2022-12-21 Thread Thomas Klausner
Module Name:src
Committed By:   wiz
Date:   Wed Dec 21 09:33:35 UTC 2022

Modified Files:
src/tests/lib/libc/locale: t_mbstowcs.c

Log Message:
adapt mbstowcs_basic test for unicode table update

reformat so it's easier to find which result data belongs to which input


To generate a diff of this commit:
cvs rdiff -u -r1.2 -r1.3 src/tests/lib/libc/locale/t_mbstowcs.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.



CVS commit: src/tests/lib/libc/locale

2019-07-28 Thread Christos Zoulas
Module Name:src
Committed By:   christos
Date:   Sun Jul 28 13:46:45 UTC 2019

Modified Files:
src/tests/lib/libc/locale: Makefile
Added Files:
src/tests/lib/libc/locale: t_wcsrtombs.c

Log Message:
PR/54414: Valery Ushakov: add a test for wcsrtombs(3) doesn't update the
source argument on conversion error


To generate a diff of this commit:
cvs rdiff -u -r1.12 -r1.13 src/tests/lib/libc/locale/Makefile
cvs rdiff -u -r0 -r1.1 src/tests/lib/libc/locale/t_wcsrtombs.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Modified files:

Index: src/tests/lib/libc/locale/Makefile
diff -u src/tests/lib/libc/locale/Makefile:1.12 src/tests/lib/libc/locale/Makefile:1.13
--- src/tests/lib/libc/locale/Makefile:1.12	Wed Aug 16 09:53:20 2017
+++ src/tests/lib/libc/locale/Makefile	Sun Jul 28 09:46:45 2019
@@ -1,4 +1,4 @@
-# $NetBSD: Makefile,v 1.12 2017/08/16 13:53:20 joerg Exp $
+# $NetBSD: Makefile,v 1.13 2019/07/28 13:46:45 christos Exp $
 
 .include 
 
@@ -10,6 +10,7 @@ TESTS_C+=	t_mbsnrtowcs
 TESTS_C+=	t_mbtowc
 TESTS_C+=	t_wcscspn
 TESTS_C+=	t_wcspbrk
+TESTS_C+=	t_wcsrtombs
 TESTS_C+=	t_wcsspn
 TESTS_C+=	t_wcstod
 TESTS_C+=	t_wctomb

Added files:

Index: src/tests/lib/libc/locale/t_wcsrtombs.c
diff -u /dev/null src/tests/lib/libc/locale/t_wcsrtombs.c:1.1
--- /dev/null	Sun Jul 28 09:46:45 2019
+++ src/tests/lib/libc/locale/t_wcsrtombs.c	Sun Jul 28 09:46:45 2019
@@ -0,0 +1,66 @@
+/*	$NetBSD: t_wcsrtombs.c,v 1.1 2019/07/28 13:46:45 christos Exp $	*/
+
+/*-
+ * Copyright (c) 2019 The NetBSD Foundation, Inc.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
+ * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
+ * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+ * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
+ * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include 
+__RCSID("$NetBSD: t_wcsrtombs.c,v 1.1 2019/07/28 13:46:45 christos Exp $");
+
+#include 
+#include 
+#include 
+#include 
+
+ATF_TC(wcsrtombs_advance);
+ATF_TC_HEAD(wcsrtombs_advance, tc)
+{
+	atf_tc_set_md_var(tc, "descr", "Test wcsrtombs(3) advances "
+	"the source pointer to the first illegal byte");
+}
+
+ATF_TC_BODY(wcsrtombs_advance, tc)
+{
+	wchar_t label[] = L"L" L"\u0403" L"bel";
+	const wchar_t *wp = label;
+	char lbuf[128];
+	mbstate_t mbstate;
+	size_t n;
+
+	memset(, 0, sizeof(mbstate));
+	memset(lbuf, 0, sizeof(lbuf));
+	n = wcsrtombs(lbuf, , sizeof(lbuf), );
+
+	ATF_REQUIRE_EQ(n, (size_t)-1);
+	ATF_REQUIRE_EQ(errno, EILSEQ);
+	ATF_REQUIRE_EQ(wp - label, 1);
+}
+
+ATF_TP_ADD_TCS(tp)
+{
+
+	ATF_TP_ADD_TC(tp, wcsrtombs_advance);
+	return atf_no_error();
+}



CVS commit: src/tests/lib/libc/locale

2019-07-28 Thread Christos Zoulas
Module Name:src
Committed By:   christos
Date:   Sun Jul 28 13:46:45 UTC 2019

Modified Files:
src/tests/lib/libc/locale: Makefile
Added Files:
src/tests/lib/libc/locale: t_wcsrtombs.c

Log Message:
PR/54414: Valery Ushakov: add a test for wcsrtombs(3) doesn't update the
source argument on conversion error


To generate a diff of this commit:
cvs rdiff -u -r1.12 -r1.13 src/tests/lib/libc/locale/Makefile
cvs rdiff -u -r0 -r1.1 src/tests/lib/libc/locale/t_wcsrtombs.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.



Re: CVS commit: src/tests/lib/libc/locale

2017-12-01 Thread Robert Elz
Date:Sat, 2 Dec 2017 00:09:29 +0100
From:Joerg Sonnenberger 
Message-ID:  <20171201230929.ga13...@britannica.bec.de>

  | This is *not* true. With C11 the standard is very explicit that return
  | must discard excessive precision. Even before, it was implied that there
  | is an implicit cast.

OK, but for this purpose it doesn't really matter - the purpose of the
test is not to test the compiler, or floating point arithmetic, but that
the locale functions work properly.

By all means add more tests that test the compiler, and floating point,
and file PRs on bugs they uncover.

kre



Re: CVS commit: src/tests/lib/libc/locale

2017-12-01 Thread Joerg Sonnenberger
On Fri, Dec 01, 2017 at 01:08:35AM +, Robert Elz wrote:
> Module Name:  src
> Committed By: kre
> Date: Fri Dec  1 01:08:35 UTC 2017
> 
> Modified Files:
>   src/tests/lib/libc/locale: t_sprintf.c
> 
> Log Message:
> Since the C standard allows for intermediate floating results to contain
> more precision bits than the data type expects, but (kind of obviously)
> does not allow such values to be stored in memory, expecting the value
> returned from strtod() (an intermediate result) to be identical (that is,
> equal) to a stored value is incorrect.

This is *not* true. With C11 the standard is very explicit that return
must discard excessive precision. Even before, it was implied that there
is an implicit cast.

Joerg


Re: CVS commit: src/tests/lib/libc/locale

2017-11-30 Thread Robert Elz
Date:Thu, 30 Nov 2017 23:09:07 +0100
From:Manuel Bouyer 
Message-ID:  <20171130220907.ga2...@antioche.eu.org>

  | Shouldn't it be made Xfail on i386 in this case ?

I don't think so, especially not now the problem is understood - it is
trivial to make it work on i386, the only question is which is the best
way to do that.Right now I have -ffloat-store added to i386 builds
of this one file (not committed) which works, but I am not sure that
just reverting to the test for (close enough) is not better.  In fact
while composing this e-mail I have convinced myself that it is, so that
is what I am proposing to do.

An xfail of this test would give the impression that there's something
broken about locales on i386, which isn't the case at all (or not in any
way relevant to this test.)

A new test of simple floating point arith / functions / whatever, could
possibly xfail on i386 if it is actually appropriate - however it seems
that the C standards actually say that giving more accurate results than
the (floating) data type can hold is actually perfectly OK, so there is
actually nothing broken except the test, which is assuming that does not
happen, and should not be - either by forcing it using a compiler flag,
or by simply coding for it properly.

Another way to handle this, would be to change the value being tested
to one that can be represented perfectly in less than 56 mantissa bits.
That is, if more bits are provided, all of them will be 0.   I don't
think that's really the right way forward though.

kre



Re: CVS commit: src/tests/lib/libc/locale

2017-11-30 Thread Manuel Bouyer
On Thu, Nov 30, 2017 at 06:16:10AM +0700, Robert Elz wrote:
> Date:Wed, 29 Nov 2017 16:51:56 +
> From:Taylor R Campbell 
> 
> Message-ID:  <20171129165637.6fa4960...@jupiter.mumble.net>
> 
>   | This is starting to smell like a compiler bug in fp correctness...but
>   | I'm out of time to diagnose it further.
> 
> In case anyone missed it, the i386 ATF test on b5 failed the exact same way
> (same values) as my Xen DomU i386 test.   But that was as expected I think.
> 
> Since this has now devolved to a discussion of how i386 FP works, and
> how the compiler generates code to use it, I'm out of this discussion from
> here on (I will send a message on port-i386 and tech-userlevel to see if
> someone with i386 FP knowledge can work out who/what is at fault here.)
> 
> Unless someone finds a fix, or at least finds the source of the problem,
> and files a PR,  I will return this test to "succeeding" status (by "hiding"
> the problem, as Joerg put it).  This test is not the place to diagnose either
> compiler issues, or i386 floating point issues.   If we need a test for those,
> please add one - elsewhere.

Shouldn't it be made Xfail on i386 in this case ?

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--


Re: CVS commit: src/tests/lib/libc/locale

2017-11-29 Thread Robert Elz
Date:Wed, 29 Nov 2017 16:51:56 +
From:Taylor R Campbell 
Message-ID:  <20171129165637.6fa4960...@jupiter.mumble.net>

  | This is starting to smell like a compiler bug in fp correctness...but
  | I'm out of time to diagnose it further.

In case anyone missed it, the i386 ATF test on b5 failed the exact same way
(same values) as my Xen DomU i386 test.   But that was as expected I think.

Since this has now devolved to a discussion of how i386 FP works, and
how the compiler generates code to use it, I'm out of this discussion from
here on (I will send a message on port-i386 and tech-userlevel to see if
someone with i386 FP knowledge can work out who/what is at fault here.)

Unless someone finds a fix, or at least finds the source of the problem,
and files a PR,  I will return this test to "succeeding" status (by "hiding"
the problem, as Joerg put it).  This test is not the place to diagnose either
compiler issues, or i386 floating point issues.   If we need a test for those,
please add one - elsewhere.

kre



Re: CVS commit: src/tests/lib/libc/locale

2017-11-29 Thread Taylor R Campbell
> Date: Wed, 29 Nov 2017 09:14:26 +0100
> From: Martin Husemann 
> 
> (gdb) info float
>   R7: Valid   0xc00cc0e6b7318fc50481 -12345.678979  
> =>R6: Valid   0xc00cc0e6b7318fc50800 -12345.678979  
>   R5: Empty   0xc00cc0e6b7318fc50800
> [...]
> Control Word:0x037f   IM DM ZM OM UM PM
>PC: Extended Precision (64-bits)
>RC: Round to nearest

Here R7 contains 0xc00cc0e6b7318fc50481, the value that strtod
returned, and R6 contains 0xc00cc0e6b7318fc50800, the value that was
stored in the program.  We switched in 6.99.26 from default 53-bit
precision to default 64-bit precision.

I tried running my program on netbsd-6.  It passed just fine.  I made
the following two changes:

1. replace double by long double
2. set the fp control word to 0x307f

With either one individually and -O0, it still passes.  With both of
them together and -O0, it fails and gives 0xc00cc0e6b7318fc50481 as
the answer from strtod.  With just (2) and -O2, it also fails and
gives 0xc00cc0e6b7318fc50481 as the answer from strtod.

This is starting to smell like a compiler bug in fp correctness...but
I'm out of time to diagnose it further.


Re: CVS commit: src/tests/lib/libc/locale

2017-11-29 Thread Martin Husemann
For the gcc 5.5 version:

30  if (!(d == t->double_value)) {
(gdb) x/16i $pc
=> 0x804887c :  fldl   0x4(%ebx)
   0x804887f :  fucomp %st(2)
   0x8048881 :  fnstsw %ax
   0x8048883 :  sahf   
   0x8048884 :  jp 0x8048891 
   0x8048886 :  jne0x8048891 

and after the sahf:

(gdb) info float
  R7: Valid   0xc00cc0e6b7318fc50481 -12345.678979  
=>R6: Valid   0xc00cc0e6b7318fc50800 -12345.678979  
  R5: Empty   0xc00cc0e6b7318fc50800
  R4: Empty   0x
  R3: Empty   0x
  R2: Empty   0x
  R1: Empty   0x
  R0: Empty   0x

Status Word: 0x3120  PE C0 
   TOP: 6
Control Word:0x037f   IM DM ZM OM UM PM
   PC: Extended Precision (64-bits)
   RC: Round to nearest
Tag Word:0x0fff
Instruction Pointer: 0x17:0x0804887f
Operand Pointer: 0x1f:0x08049cd0
Opcode:  0xddea

and the "jne" is taken.

Martin


Re: CVS commit: src/tests/lib/libc/locale

2017-11-29 Thread Martin Husemann
On Wed, Nov 29, 2017 at 09:03:50AM +0100, Martin Husemann wrote:
> On Wed, Nov 29, 2017 at 06:12:02AM +, Taylor R Campbell wrote:
> > (My guess is that there's something screwy with i387 long doubles, but
> > I don't have a good guess about where that screwiness might be
> > happening without single-stepping through it.)
> 
> My blame is on qemu.

Heh, misread the test code. Duh!

Martin


Re: CVS commit: src/tests/lib/libc/locale

2017-11-28 Thread Robert Elz
Date:Wed, 29 Nov 2017 06:12:02 +
From:Taylor R Campbell 
Message-ID:  <20171129061642.e8dcb60...@jupiter.mumble.net>

  | That's pretty interesting!

That is what I thought, it was certainly not what I expected.

  | Can you reproduce it in a small isolated program like the attached
  | one?

I will try later today, but I think I'll try something simpler first.

Since we know what bit pattern is in the variables, it should
be possible to simply start with values containing those patterns,
and just compare, & subtract, and see what happens.

The strtod() and setlocale() are most likely just window dressing,
and would make determining what is going on more difficult, unless
they do turn out to be affecting things.

I doubt there is anything very subtle (as in which addresses happen
to be used, or whatever) - this test has undergone significant alterations,
and it keeps behaving exactly the same way, every time, on i386 (and
what I also wasn't sure would happen, on "real" i386 (or as real as Xen
approximates, which for floating point, should be quite good) and on
qemu (we should see the results from that sometime tomorrow.)

kre



Re: CVS commit: src/tests/lib/libc/locale

2017-11-28 Thread Taylor R Campbell
> Date: Wed, 29 Nov 2017 11:41:58 +0700
> From: Robert Elz 
> 
> OK, got my i386 test setup (a Xen DomU) built & running, the updated
> test failed (as it always failed on i386 before I added the epsilon
> test, which is #if 0'd out now) the results are ...
> 
> strto: [0.002429s] Failed: 
> /release/testing/src/tests/lib/libc/locale/t_sprintf.c:145: d != 
> t->double_value: In en_US.UTF-8: d=strtod(t->double_input[-12345.678900], 
> NULL)[-12345.6789 = -0x1.81cd6e631f8a1p+13] != t->double_value[-12345.6789 = 
> -0x1.81cd6e631f8a1p+13]: diff=7.9492e-13

That's pretty interesting!

Can you reproduce it in a small isolated program like the attached
one?  This program works just fine with and without -m32 on my amd64
system, but I don't have a proper i386 system handy to test.  If you
can, can you perhaps single-step through it in gdb to see what's
actually in the various registers and floating-point stack?

(My guess is that there's something screwy with i387 long doubles, but
I don't have a good guess about where that screwiness might be
happening without single-stepping through it.)
#include 
#include 
#include 
#include 
#include 
#include 
#include 

static volatile struct test {
const char *locale;
const double double_value;
const char *double_input;
} tests[] = {
{
"en_US.UTF-8",
-12345.6789,
"-12345.678900",
},
};

static void __attribute__((noinline))
h_strto(const volatile struct test *t)
{
double d, diff;

if (setlocale(LC_NUMERIC, t->locale) == NULL)
errx(1, "setlocale failed");
d = strtod(t->double_input, NULL);
diff = fabs(d - t->double_value);
if (!(d == t->double_value)) {
fprintf(stderr, "str %s\n", t->double_input);
fprintf(stderr, "exp %a %.17e\n",
t->double_value, t->double_value);
fprintf(stderr, "act %a %.17e\n", d, d);
}
}

int
main(int argc, char **argv)
{
volatile size_t i;

(void)argc;
(void)argv;

for (i = 0; i < sizeof(tests)/sizeof(tests[0]); i++)
h_strto([i]);

return 0;
}


Re: CVS commit: src/tests/lib/libc/locale

2017-11-28 Thread Taylor R Campbell
> Date: Wed, 29 Nov 2017 05:37:56 +0700
> From: Robert Elz 
> 
> I think that conclusion had been reached already (not by me...) but that's
> "Under IEEE 754-2008" right?   What about architectures that don't use IEEE
> floats?  This test should not be assuming that - we still support vax right?
> The test should be able to be run there as well.   Can we guarantee that the
> results must be identical on every port that runs NetBSD?

There's no reason the same algorithm shouldn't work on VAX too.

Even if it didn't (maybe because VAX's basic arithmetic operations
give spectacularly incorrectly rounded answers), I'd rather prioritize
reporting bugs in what we expect to be IEEE 754 floating-point
arithmetic over hiding bugs everywhere.  If it turns out that this
test is legitimately wrong on VAX, we can conditionalize it for VAX.

>   | Can you please put it back to an exact equality test and report the
>   | mismatched values in the output, with %a rather than (or in addition to) 
> %g
>   | so that we can see the precise difference in their bits when the test 
> fails?
> 
> Yes, doing that now (need to build and test twice, once with the "correct"
> code, and once where the result of the test is deliberately forced to
> fail so I can test the error string works as intended.)

Thanks!


Re: CVS commit: src/tests/lib/libc/locale

2017-11-28 Thread Robert Elz
Date:Tue, 28 Nov 2017 15:34:19 +0100
From:Joerg Sonnenberger 
Message-ID:  <20171128143418.ga8...@britannica.bec.de>

  | Hidding things until then doesn't actually fix something.

No, it doesn't, but when I made the change I wasn't hiding anything,
just doing what I thought was the correct programming technique.

  | You might try to printf them with %a instead.

Didn't know that existed, or I would have (like I said, I rarely use
floating point - mostly just for calculating percentages...) - I also
don't often read the printf(3) man page for that kind of detail.

  | The reference paper for precise conversion between binary and decimal
  | for floating point values is from 1990, which is quite surprisingly
  | late.

And well after my time.


Taylor R Campbell   said:

  | (As general advice, usually you want to use relative error, namely |actual -
  | expected|/expected, not absolute error, |actual - expected|, but that's an
  | side.)

Yes, I know that ... but here the "expected" is a known constant, so
that part of the computation was done in my head (the tests do this kind
of thing all the time - they aren't supposed to be examples of good
programming technique, just to uncover problems ... this one isn't even
really testing floating point conversions, it is testing locales, making
sure that everything works with number conversion with different locale
settings.)   I thought a relative difference of 1e-12 would be insignificant
enough - there was a note about that in the original commit message.

  | Since every number here has 11 significant digits, the result must be
  | identical from the compiler and from strtod unless one or the other is
  | buggy.

I think that conclusion had been reached already (not by me...) but that's
"Under IEEE 754-2008" right?   What about architectures that don't use IEEE
floats?  This test should not be assuming that - we still support vax right?
The test should be able to be run there as well.   Can we guarantee that the
results must be identical on every port that runs NetBSD?   If not, then
expecting them to be identical (in this test) would be too much long term.
If we want tests that are intended to be tests of floating point conversions,
assuming there aren't some already, they'd belong somewhere other than in
a test of locales, and could be tailored to the various floating formats
that we might encounter.

  | Can you please put it back to an exact equality test and report the
  | mismatched values in the output, with %a rather than (or in addition to) %g
  | so that we can see the precise difference in their bits when the test fails?

Yes, doing that now (need to build and test twice, once with the "correct"
code, and once where the result of the test is deliberately forced to
fail so I can test the error string works as intended.)

The first of those is done (while I have been typing this e-mail) - now I
have to go do the "force fail" test.   After that waiting for b5 to actually
run the test will take about a day I expect.

In the interim, I'll see if I can set up an i386 testbed to see if I can
reproduce the issue there - I might manage to get that done quicker than
b5 runs the updated test.   Perhaps.I haven't built an i386 system
(let alone run one) in ages...

kre

ps: if nothing else, this has at least finally gained this test failure
some attention, it has been consistently failing on i386 since about forever,
and seemed to simply be ignored - no-one was bothering to find out why it
was failing, it was just "one of those things" ...



Re: CVS commit: src/tests/lib/libc/locale

2017-11-28 Thread Taylor R Campbell
> Date: Tue, 28 Nov 2017 05:32:45 +0700
> From: Robert Elz 
> 
> Way back when I first learned floating point programming (something I
> have done astonishingly little of in the intervening decades) I was
> told it was *always* wrong to compare floats for exact equality - but
> of course, that was back in the days when almost all computing was
> numerical (simultaneous equation solfving, ffts, ...) and almost all
> written in fortran (the only language worthy of using) ...

That's sensible advice for most questions that a numerical algorithm
is likely to want to ask in the course of its computation, and when
the operations you're performing do not have 0.5 ulp error bounds.
(As general advice, usually you want to use relative error, namely
|actual - expected|/expected, not absolute error, |actual - expected|,
but that's an side.)

However, in this case, we are testing the map from a decimal expansion
to a floating-point number.  Under IEEE 754-2008, this operation is
required to be correctly rounded for decimal expansions of up to 20
significant digits (Sec. 5.12.2 `Details of conversion between
floating-point data and external character sequences', pp. 31--32).

Since every number here has 11 significant digits, the result must be
identical from the compiler and from strtod unless one or the other is
buggy.

Can you please put it back to an exact equality test and report the
mismatched values in the output, with %a rather than (or in addition
to) %g so that we can see the precise difference in their bits when
the test fails?


Re: CVS commit: src/tests/lib/libc/locale

2017-11-28 Thread Joerg Sonnenberger
On Tue, Nov 28, 2017 at 05:32:45AM +0700, Robert Elz wrote:
> Date:Mon, 27 Nov 2017 18:44:38 +0100
> From:Joerg Sonnenberger 
> Message-ID:  <20171127174438.ga20...@britannica.bec.de>
> 
>   | Parsing a string constant is a well-defined
>   | operation with precise result. A cross-compiler that doesn't do that
>   | correctly is simply broken.
> 
> I don't disagree with that, if you can tell me the PR number for the
> bug report on gcc (whichever version it is that the buildbots are using
> to make the i386 builds that babylony5 uses to run the tests) then I
> will happily mark the test as expected to fail on i386 until the PR
> is fixed.

Hidding things until then doesn't actually fix something.

> Tha is, of course, if that is what the problem is - it may also be that
> it is the libc strtod() on i386 that doesn't make the correct (ideal)
> conversion, and if that's true, then the PR number for that but would do
> equally well.

That would be just as big a bug.

> I am not qualified to work out which it is - all I know is that the
> numbers as printed from printf were identical, yet did not compare
> equal, and apparently are equal within 1e-7, as the test now "works".

You might try to printf them with %a instead.

> Way back when I first learned floating point programming (something I
> have done astonishingly little of in the intervening decades) I was
> told it was *always* wrong to compare floats for exact equality - but
> of course, that was back in the days when almost all computing was
> numerical (simultaneous equation solfving, ffts, ...) and almost all
> written in fortran (the only language worthy of using) ...

The reference paper for precise conversion between binary and decimal
for floating point values is from 1990, which is quite surprisingly
late.

Joerg


Re: CVS commit: src/tests/lib/libc/locale

2017-11-27 Thread Robert Elz
Date:Mon, 27 Nov 2017 18:44:38 +0100
From:Joerg Sonnenberger 
Message-ID:  <20171127174438.ga20...@britannica.bec.de>

  | Parsing a string constant is a well-defined
  | operation with precise result. A cross-compiler that doesn't do that
  | correctly is simply broken.

I don't disagree with that, if you can tell me the PR number for the
bug report on gcc (whichever version it is that the buildbots are using
to make the i386 builds that babylony5 uses to run the tests) then I
will happily mark the test as expected to fail on i386 until the PR
is fixed.

Tha is, of course, if that is what the problem is - it may also be that
it is the libc strtod() on i386 that doesn't make the correct (ideal)
conversion, and if that's true, then the PR number for that but would do
equally well.

I am not qualified to work out which it is - all I know is that the
numbers as printed from printf were identical, yet did not compare
equal, and apparently are equal within 1e-7, as the test now "works".

Way back when I first learned floating point programming (something I
have done astonishingly little of in the intervening decades) I was
told it was *always* wrong to compare floats for exact equality - but
of course, that was back in the days when almost all computing was
numerical (simultaneous equation solfving, ffts, ...) and almost all
written in fortran (the only language worthy of using) ...

kre



Re: CVS commit: src/tests/lib/libc/locale

2017-11-27 Thread Joerg Sonnenberger
On Fri, Nov 24, 2017 at 09:30:43PM +, Robert Elz wrote:
> Module Name:  src
> Committed By: kre
> Date: Fri Nov 24 21:30:43 UTC 2017
> 
> Modified Files:
>   src/tests/lib/libc/locale: t_sprintf.c
> 
> Log Message:
> When comparing doubles (any floating point values) which have been
> computed using different methods, don't expect to achieve identical
> results (here, one constant is perhaps converted to binary from a string by
> a cross compiler, the other is converted at run time).   Allow them to
> have a small difference (for now, small is < 1e-7 - the constant is ~ 1e5,
> so this is 12 orders of magnitude less) before failing (and include the
> actual difference in the error message if it does fail.) 

I don't agree with this. Parsing a string constant is a well-defined
operation with precise result. A cross-compiler that doesn't do that
correctly is simply broken.

Joerg