mlyszczek commented on issue #5253:
URL:
https://github.com/apache/incubator-nuttx/issues/5253#issuecomment-1179826351
In libvsprintf.c we have
```
#ifndef CONFIG_HAVE_LONG_LONG
# undef CONFIG_LIBC_LONG_LONG
#endif
```
So it's safe to assume if LIBC_LONG_LONG is defined so is HAVE_LONG_LONG.
I think it's both safe and logical to wrap sprintf(3) function in
LIBC_LONG_LONG.
Something like that seems to be fine:
```
#ifdef CONFIG_LIB_LONG_LONG
mount_sprintf(info, " %-10s %6llu%c %8llu%c %8llu%c %s\n", fstype,
size, sizelabel, used, usedlabel, free, freelabel,
mountpoint);
#else
mount_sprintf(info,
# if CONFIG_HAVE_LONG_LONG
"long long is enabled, but libc does not support it, printed data may be
truncated\n"
# endif
" %-10s %6ld%c %8ld%c %8ld%c %s\n", fstype,
(uint32_t)size, sizelabel, (uint32_t)used, usedlabel,
(uint32_t)free, freelabel,
mountpoint);
#endif
```
It still would make 4gb sd cards to not be properly printed, but at least
programmer would have warning about it so he could react properly if needed.
I wouldn't really wrap type declaration with LIBC_LONG_LONG - it looks
illogical, and that define was not created for that purpose.
As @normanr said, it's not really possible to determine overflow inside of
vsprintf(3) via va_arg(3). va_arg(3) requires you to know what type you are
taking from the argument stack.
Consuming long long without LIBC_LONG_LONG kinda defies that flag I think,
because you would have to have code to parse long long. And it would be even
harder to consume long long without HAVE_LONG_LONG - long long must be *at
least* 64bits long, not *exactly*, so without having a way to probe compile for
sizeof(long long) it's impossible to implement it in portable way.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
