Skip to contentSkip to conversation

kconfig: switch to "long long" for sanity

PATCH In review Kees Cook 3 participants 4 messages Jul 18, 2013

Subsystems (2)
lore
Share & tools
lore

Kees Cook

author
#0 lore raw

PATCH v2 1/1 kconfig: switch to "long long" for sanity

Instead of using "long" for kconfig "hex" and "range" values, which may change in size depending on the host architecture, use "long long". This will allow values greater than INT_MAX on 32-bit hosts when cross compiling.

---
v2:
- use "int" for base, since that's what strtoll expects, thanks to Geert

---
 scripts/kconfig/symbol.c |   19 ++++++++++---------
 1 file changed, 10 insertions(+), 9 deletions(-)
scripts/kconfig/symbol.c +10 -9
index d550300..5d850e7 100644
@@ -136,7 +136,7 @@ static struct property *sym_get_range_prop(struct symbol *sym)
 	return NULL;
 }
 
-static long sym_get_range_val(struct symbol *sym, int base)
+static long long sym_get_range_val(struct symbol *sym, int base)
 {
 	sym_calc_value(sym);
 	switch (sym->type) {
@@ -149,13 +149,14 @@ static long sym_get_range_val(struct symbol *sym, int base)
 	default:
 		break;
 	}
-	return strtol(sym->curr.val, NULL, base);
+	return strtoll(sym->curr.val, NULL, base);
 }
 
 static void sym_validate_range(struct symbol *sym)
 {
 	struct property *prop;
-	long base, val, val2;
+	int base;
+	long long val, val2;
 	char str[64];
 
 	switch (sym->type) {
@@ -171,7 +172,7 @@ static void sym_validate_range(struct symbol *sym)
 	prop = sym_get_range_prop(sym);
 	if (!prop)
 		return;
-	val = strtol(sym->curr.val, NULL, base);
+	val = strtoll(sym->curr.val, NULL, base);
 	val2 = sym_get_range_val(prop->expr->left.sym, base);
 	if (val >= val2) {
 		val2 = sym_get_range_val(prop->expr->right.sym, base);
@@ -179,9 +180,9 @@ static void sym_validate_range(struct symbol *sym)
 			return;
 	}
 	if (sym->type == S_INT)
-		sprintf(str, "%ld", val2);
+		sprintf(str, "%lld", val2);
 	else
-		sprintf(str, "0x%lx", val2);
+		sprintf(str, "0x%llx", val2);
 	sym->curr.val = strdup(str);
 }
 
@@ -594,7 +595,7 @@ bool sym_string_valid(struct symbol *sym, const char *str)
 bool sym_string_within_range(struct symbol *sym, const char *str)
 {
 	struct property *prop;
-	long val;
+	long long val;
 
 	switch (sym->type) {
 	case S_STRING:
@@ -605,7 +606,7 @@ bool sym_string_within_range(struct symbol *sym, const char *str)
 		prop = sym_get_range_prop(sym);
 		if (!prop)
 			return true;
-		val = strtol(str, NULL, 10);
+		val = strtoll(str, NULL, 10);
 		return val >= sym_get_range_val(prop->expr->left.sym, 10) &&
 		       val <= sym_get_range_val(prop->expr->right.sym, 10);
 	case S_HEX:
@@ -614,7 +615,7 @@ bool sym_string_within_range(struct symbol *sym, const char *str)
 		prop = sym_get_range_prop(sym);
 		if (!prop)
 			return true;
-		val = strtol(str, NULL, 16);
+		val = strtoll(str, NULL, 16);
 		return val >= sym_get_range_val(prop->expr->left.sym, 16) &&
 		       val <= sym_get_range_val(prop->expr->right.sym, 16);
 	case S_BOOLEAN:
Signature · 6 lines
1.7.9.5


-- 
Kees Cook
Chrome OS Security
Acked-by on v2 1/1
#1 lore raw
Quoted 6 lines · Kees Cook

Instead of using "long" for kconfig "hex" and "range" values, which may change in size depending on the host architecture, use "long long". This will allow values greater than INT_MAX on 32-bit hosts when cross compiling.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

#2 lore raw

Kees, Geert, All,

On 2013-07-18 22:00 +0200, Geert Uytterhoeven spake thusly:

Quoted 9 lines · Kees Cook
Quoted 6 lines

Instead of using "long" for kconfig "hex" and "range" values, which may change in size depending on the host architecture, use "long long". This will allow values greater than INT_MAX on 32-bit hosts when cross compiling.

Ok, thanks, I'll take in my tree.

Is it material for -rc-fixes, or can it wait in -for-next?

My gut feelings is that it does not fix an existing breakage, but only a potential problem in the future, so it would be a candidate for -for-next. Agreed?

Regards,
Yann E. MORIN.

Signature · 6 lines
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
author
#3 lore raw
Quoted 13 lines · Yann E. MORIN

Kees, Geert, All,

On 2013-07-18 22:00 +0200, Geert Uytterhoeven spake thusly:

Quoted 9 lines · Kees Cook
Quoted 6 lines

Instead of using "long" for kconfig "hex" and "range" values, which may change in size depending on the host architecture, use "long long". This will allow values greater than INT_MAX on 32-bit hosts when cross compiling.

Quoted 7 lines

Ok, thanks, I'll take in my tree.

Is it material for -rc-fixes, or can it wait in -for-next?

My gut feelings is that it does not fix an existing breakage, but only a potential problem in the future, so it would be a candidate for -for-next. Agreed?

Correct. I'm not aware of anything in the tree that currently uses

Quoted 1 line

INT_MAX values in kconfig.

-Kees

Signature · 2 lines
Kees Cook
Chrome OS Security