Do a better job of reporting invalid numeric constants in arithmetic exprs.

For example, given $(( 08 + 1 )) (or similar) instead of reporting
"expecting end of expression"  - the generic error for parse failed,
which happened as this was parsed as $(( 0 8 + 1 )) because the 8
could not be a part of an octal constant, and that expr makes no sense -
instead say "unexpected '8' (out of range) in numeric constant: 08"
which makes the cause of the error more obvious.

NFC for valid expressions, just the error message (and the way the
error is detected).
This commit is contained in:
kre 2017-12-17 04:06:03 +00:00
parent 743f435a2d
commit 84c609adca
1 changed files with 10 additions and 2 deletions

View File

@ -1,4 +1,4 @@
/* $NetBSD: arith_token.c,v 1.6 2017/07/24 13:21:14 kre Exp $ */
/* $NetBSD: arith_token.c,v 1.7 2017/12/17 04:06:03 kre Exp $ */
/*-
* Copyright (c) 2002
@ -39,7 +39,7 @@
#include <sys/cdefs.h>
#ifndef lint
__RCSID("$NetBSD: arith_token.c,v 1.6 2017/07/24 13:21:14 kre Exp $");
__RCSID("$NetBSD: arith_token.c,v 1.7 2017/12/17 04:06:03 kre Exp $");
#endif /* not lint */
#include <inttypes.h>
@ -87,6 +87,14 @@ arith_token(void)
* strtoimax() stops...
*/
a_t_val.val = strtoimax(buf, &end, 0);
if (is_in_name(*end)) {
token = *end;
while (is_in_name(*++end))
continue;
error("arithmetic: unexpected '%c' "
"(out of range) in numeric constant: "
"%.*s", token, (int)(end - buf), buf);
}
arith_buf = end;
VTRACE(DBG_ARITH, ("Arith token ARITH_NUM=%jd\n",
a_t_val.val));