Fix false positive for mvscanw tests on big endian machines.

When conversion specifier is not a derivative form of "%s", retrieve
input as 32bit integer, and then convert to string literal. Then we
can avoid interpretation from ASCII code to integer, which is
apparently byte-order depended.
This commit is contained in:
rin 2020-06-20 07:50:16 +00:00
parent 4562851ebb
commit 669f5e8178
2 changed files with 13 additions and 6 deletions

View File

@ -1,4 +1,4 @@
/* $NetBSD: curses_commands.c,v 1.9 2019/05/26 07:47:37 blymn Exp $ */
/* $NetBSD: curses_commands.c,v 1.10 2020/06/20 07:50:16 rin Exp $ */
/*-
* Copyright 2009 Brett Lymn <blymn@NetBSD.org>
@ -3061,7 +3061,7 @@ cmd_mvprintw(int nargs, char **args)
void
cmd_mvscanw(int nargs, char **args)
{
int y, x;
int y, x, val;
char string[256];
if (check_arg_count(nargs, 3) == 1)
@ -3081,7 +3081,13 @@ cmd_mvscanw(int nargs, char **args)
/* XXX - call2 */
report_count(2);
report_return(mvscanw(y, x, args[2], &string));
if (strchr(args[2], 's') != NULL)
report_return(mvscanw(y, x, args[2], &string));
else {
/* XXX assume 32bit integer */
report_return(mvscanw(y, x, args[2], &val));
snprintf(string, sizeof(string), args[2], val);
}
report_status(string);
}

View File

@ -1,11 +1,12 @@
# XXX For this test, only one string or 32bit integer are supported as
# conversion specifiers at the moment.
include start
input "testing 1 2 3\n"
call2 OK "testing" mvscanw 3 5 "%s"
input "testing 1 2 3\n"
call2 OK "test" mvscanw 3 5 "%4s"
# 50 will translate into number 2 in ascii
input "50 12\n"
call2 OK "2" mvscanw 3 5 "%d"
call2 OK "50" mvscanw 3 5 "%d"
input "aa bb 50 12\n"
# expect ERR because input has alpha and scanw wants integer
call2 ERR "2" mvscanw 3 5 "%d"
call2 ERR "50" mvscanw 3 5 "%d"