xiaoxiang781216 commented on PR #6613: URL: https://github.com/apache/incubator-nuttx/pull/6613#issuecomment-1186195406
> How about? > > ``` > #ifndef CONFIG_LIBC_LONG_LONG > DEBUGASSERT(strcmp(fmt, "%ll")); > #endif > ``` > > This has 0 cost in production, and you usually want to run your code with DEBUGASSERT() enabled before releasing, so programmer will be notified about trying to print ll when ll is not supported. Then, if programmer wants to ignore this, responsibility of broken code lies on him - and not on nuttx. This of course forces solution where nuttx simply don't print ll without CONFIG_LIBC_LONG_LONG. It isn't good since there are many places which use uint64_t when possible, but the result is seldom larger than ULONG_MAX, or the user may prefer to save the coe space and then accept the wrong printf output(e.g. log or procfs). > > If you want to get creative, you could also add trivial `strings nuttx | grep -E "%u?ll"` to build process if CONFIG_LIBC_LONG_LONG is not defied and warn user about the situation. > > With these solutions after error/warning programmer can either enable CONFIG_LIBC_LONG_LONG or adapt code to use only int. > > This wouldn't be acceptable in Linux world, but in small embedded with rtos? I think it's acceptable - and maybe even desired as it saves space. But, I add the check before down cast: https://github.com/apache/incubator-nuttx/pull/6613/files#diff-befc8e04ddb3722f024f65ffd7648aac1cb24846d2b80fff6328e3cb5862220fR1042-R1044 https://github.com/apache/incubator-nuttx/pull/6613/files#diff-befc8e04ddb3722f024f65ffd7648aac1cb24846d2b80fff6328e3cb5862220fR1217-R1219 which could notice the user some bad thing happen in debugging mode. -- 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
