mlyszczek commented on PR #6613: URL: https://github.com/apache/incubator-nuttx/pull/6613#issuecomment-1186433174
> @hartmannathan the patch already add the debug assert in case the value > ULONG_MAX. It does, but in unpredictable way. Assert will only trigger if in debug runtime, you try to print something bigger than uint32_t, and this may not trigger in debug, but will malform data on production. Second thing is, "x" is signed, and comparision is to unsigned. ```if (-1ll < ULONG_MAX)``` will be false negative thus triggering assert, in fact, half of the negative numbers will trigger assert here (assuming ```sizeof(long) != sizeof(long long)```, when they are equal - only -1 will trigger false assert). I have a little anxiety with these runtime checks. These checks may never trigger in a debug build, but on production variable might suddenly (and we all know it eventually will:)) get bigger than long, and someday this will ruin somebody's day. Note, that these checks are not only for mere printf(), but also for sprintf() which in fact may be used for serious business (but so can fprintf(), ie. to pass big number to different CPU via serial link). Safeset approach would be "you want to print %ll? enable support for it or patch your code to include dangerous stuff yourself". If there are places where long long is used and (s)printfed, but we don't care if they overflow or not, these values should be printed as %l and explicitly casted down to (long). Anything else seems like a time bomb. @hartmannathan just out of curiosity, how do you want to print ```#error``` when "%ll" was used? Unless I missunderstood you and this is not compiler ```#error```, I don't think preprocesor can detect "%ll" in string? -- 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
