hartmannathan commented on PR #6613:
URL: https://github.com/apache/incubator-nuttx/pull/6613#issuecomment-1186377358

   > 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.
   > 
   > 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.
   
   @mlyszczek I like this idea. This (or something similar) could really save 
developers a lot of frustration. If it works for `%llu` then the same idea 
could work for `%f` when printf() is compiled without support for printing 
floats. Try to print a float and you'll get an error. This feature could be 
made optional by toggling a Kconfig under Debug Options.
   
   Another alternative, if CONFIG_LIBC_LONG_LONG is not defined, is to print 
`#error` when an unsupported format specifier is used. I recall at least one 
libc that does that for `%f` when not supported.
   
   In my opinion, it is better to print something that obviously indicates an 
error than to risk printing incorrect information (which might be consumed by 
other programs leading to very hard-to-find bugs) by truncating a uint64_t and 
printing just the lower 32 bits.
   
   I understand the point @xiaoxiang781216 is making that usually a 64-bit 
variable would contain a 32-bit number. I would be open to compromising and 
printing the lower 32 bits IF the upper 32 bits are 0 and printing `#error` if 
any upper bits are 1.
   
   The point is: Either print CORRECT information or print an obvious error. 
But don't print incorrect information under any circumstances.


-- 
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

Reply via email to