kernel/scripts/kconfig/confdata.c, branch linux-4.16.y

kconfig: Avoid format overflow warning from GCC 8.1

2018-06-11T20:48:14Z

commit 2ae89c7a82ea9d81a19b4fc2df23bef4b112f24e upstream. In file included from scripts/kconfig/zconf.tab.c:2485: scripts/kconfig/confdata.c: In function ‘conf_write’: scripts/kconfig/confdata.c:773:22: warning: ‘%s’ directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=] sprintf(newname, "%s%s", dirname, basename); ^~ scripts/kconfig/confdata.c:773:19: note: assuming directive output of 7 bytes sprintf(newname, "%s%s", dirname, basename); ^~~~~~ scripts/kconfig/confdata.c:773:2: note: ‘sprintf’ output 1 or more bytes (assuming 4104) into a destination of size 4097 sprintf(newname, "%s%s", dirname, basename); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ scripts/kconfig/confdata.c:776:23: warning: ‘.tmpconfig.’ directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=] sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid()); ^~~~~~~~~~~ scripts/kconfig/confdata.c:776:3: note: ‘sprintf’ output between 13 and 4119 bytes into a destination of size 4097 sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid()); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Increase the size of tmpname and newname to make GCC happy. Signed-off-by: Nathan Chancellor Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman

kconfig: add xstrdup() helper

2018-03-01T15:26:47Z

We already have xmalloc(), xcalloc(), and xrealloc((). Add xstrdup() as well to save tedious error handling. Signed-off-by: Masahiro Yamada

kconfig: add xrealloc() helper

2018-02-10T02:26:04Z

We already have xmalloc(), xcalloc(). Add xrealloc() as well to save tedious error handling. Signed-off-by: Masahiro Yamada

kconfig: make conf_unsaved a local variable of conf_read()

2018-01-21T15:49:31Z

conf_unsaved is initialized by conf_read_simple(), but it is possible to move it to conf_read() so that it can be a local variable. Signed-off-by: Masahiro Yamada

kconfig: drop 'boolean' keyword

2018-01-21T15:49:29Z

No more users of this keyword. Drop it according to the notice by commit 6341e62b212a ("kconfig: use bool instead of boolean for type definition attributes"). Signed-off-by: Masahiro Yamada Acked-by: Luis R. Rodriguez

kconfig: add unexpected data itself to warning

2016-05-10T15:20:19Z

If the .config parser runs into unexpected data it emits warnings like: .config:6911:warning: unexpected data Add the unexpected data itself to this warning. That makes it easier to discover what is actually going wrong: .config:6911:warning: unexpected data: CONFOG_CHARGER_TPS65217=m Signed-off-by: Paul Bolle Signed-off-by: Michal Marek

unbreak allmodconfig KCONFIG_ALLCONFIG=...

2016-02-01T14:12:40Z

Prior to 3.13 make allmodconfig KCONFIG_ALLCONFIG=/dev/null used to be equivalent to make allmodconfig; these days it hardwires MODULES to n. In fact, any KCONFIG_ALLCONFIG that doesn't set MODULES explicitly is treated as if it set it to n. Regression had been introduced by commit cfa98f ("kconfig: do not override symbols already set"); what happens is that conf_read_simple() does sym_calc_value(modules_sym) on exit, which leaves SYMBOL_VALID set and has conf_set_all_new_symbols() skip modules_sym. It's pretty easy to fix - simply move that call of sym_calc_value() into the callers, except for the ones in KCONFIG_ALLCONFIG handling. Objections? Signed-off-by: Al Viro Fixes: cfa98f2e0ae9 ("kconfig: do not override symbols already set") Signed-off-by: Michal Marek

kconfig: Delete unnecessary checks before the function call "sym_calc_value"

2015-08-19T14:41:02Z

The sym_calc_value() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring Signed-off-by: Michal Marek

kconfig: Remove unnecessary prototypes from headers

2015-02-25T14:00:17Z

Signed-off-by: Michal Marek

kconfig: use va_end to match corresponding va_start

2015-01-27T15:52:43Z

Although on some systems va_end is a no-op, it is good practice to use va_end, especially since the manual states: "Each invocation of va_start() must be matched by a corresponding invocation of va_end() in the same function." Signed-off-by: Colin Ian King Signed-off-by: Michal Marek