You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@nuttx.apache.org by GitBox <gi...@apache.org> on 2022/07/16 10:17:26 UTC

[GitHub] [incubator-nuttx] mlyszczek commented on pull request #6613: libc/stdio: Support "long long" type if CONFIG_HAVE_LONG_LONG is enabled

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

   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.


-- 
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-unsubscribe@nuttx.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org