Re: [linux-next:master 6914/8209] drivers/watchdog/watchdog_core.c:283:65: warning: '%d' directive output may be truncated writing between 1 and 10 bytes into a region of size 8

On 7/21/26 19:49, kernel test robot wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> head:   290aaf24a551d5a0dce037e3fab30820f9113a10
> commit: e9f47fe866d6b0aa026fe99df94f8cc2fadc2638 [6914/8209] watchdog: take all OF aliases into account when assigning id
> config: csky-allmodconfig (https://download.01.org/0day-ci/archive/20260722/[email protected]/config)
> compiler: csky-linux-gcc (GCC) 16.1.0
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260722/[email protected]/reproduce)
> 
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <[email protected]>
> | Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
> 
> All warnings (new ones prefixed by >>):
> 
>     drivers/watchdog/watchdog_core.c: In function '___watchdog_register_device':
>>> drivers/watchdog/watchdog_core.c:283:65: warning: '%d' directive output may be truncated writing between 1 and 10 bytes into a region of size 8 [-Wformat-truncation=]
>       283 |                         snprintf(alias, sizeof(alias), "watchdog%d", id);
>           |                                                                 ^~
>     drivers/watchdog/watchdog_core.c:283:56: note: directive argument in the range [0, 2147483647]
>       283 |                         snprintf(alias, sizeof(alias), "watchdog%d", id);
>           |                                                        ^~~~~~~~~~~~
>     drivers/watchdog/watchdog_core.c:283:25: note: 'snprintf' output between 10 and 19 bytes into a destination of size 16
>       283 |                         snprintf(alias, sizeof(alias), "watchdog%d", id);
>           |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> 
> vim +283 drivers/watchdog/watchdog_core.c
> 
>     240	
>     241	static int ___watchdog_register_device(struct watchdog_device *wdd)
>     242	{
>     243		int ret, min_id, id = -1;
>     244		struct device_node *np;
>     245		char alias[16];
>     246	
>     247		if (wdd == NULL || wdd->info == NULL || wdd->ops == NULL)
>     248			return -EINVAL;
>     249	
>     250		/* Mandatory operations need to be supported */
>     251		if (!wdd->ops->start || (!wdd->ops->stop && !wdd->max_hw_heartbeat_ms))
>     252			return -EINVAL;
>     253	
>     254		watchdog_check_min_max_timeout(wdd);
>     255	
>     256		/*
>     257		 * Note: now that all watchdog_device data has been verified, we
>     258		 * will not check this anymore in other functions. If data gets
>     259		 * corrupted in a later stage then we expect a kernel panic!
>     260		 */
>     261	
>     262		/* Use alias for watchdog id if possible */
>     263		if (wdd->parent) {
>     264			ret = of_alias_get_id(wdd->parent->of_node, "watchdog");
>     265			if (ret >= 0)
>     266				id = ida_alloc_range(&watchdog_ida, ret, ret,
>     267						     GFP_KERNEL);
>     268		}
>     269	
>     270		/*
>     271		 * Find an id which is not pre-assigned via a DT alias to some
>     272		 * other, possibly not yet probed, watchdog device.
>     273		 */
>     274		if (id < 0) {
>     275			np = of_find_node_by_path("/aliases");
>     276	
>     277			for (min_id = 0; ; min_id = id + 1) {
>     278				id = ida_alloc_range(&watchdog_ida, min_id, MAX_DOGS - 1,
>     279						     GFP_KERNEL);
>     280				if (!np || id < 0)
>     281					break;
>     282	
>   > 283				snprintf(alias, sizeof(alias), "watchdog%d", id);

Sure, never mind that id can only be in the range of 0 .. MAX_DOGS - 1, or 1 .. 31.

I hate clueless compilers, but then I don't want to be bugged by this until
I die either. Rasmus, any suggestion ? We could make alias a 20-byte string,
or validate check the range of id. Not sure what would be less annoying.
Any preference or other idea ?

Don't resend the patch, I'll rebase and take care of it after we figure out
how to silence the compiler.

Thanks,
Guenter