On Thu, 5 Nov 2020 18:35:52 GMT, Thomas Stuefe <stu...@openjdk.org> wrote:
>> Hi, >> >> I think the compiler is correct. The 3 in "%.3d" of the second argument is >> precision, not scale. Which is the *minimum* numbers of digits to be printed. >> >> So we get: >> >> (void)snprintf(tbuf, ltbuf, >> "%s.%.3d %s", timestamp_date_time, >> (int)(millisecs), timestamp_timezone); >> >> with timestamp_date_time = DT_SIZE = 20 and timestamp_timezone = TZ_SIZE = 56 >> >> and the second argument prints at least three digits but possibly more if >> the argument is longer. MAX_INT is 2147483647. So length could be 10. >> >> 56 + 20 + 10 = 86. > > ... so the problem would be that the compiler does not believe us that > millisecs will be always <1000. And there is no way to truncate output for > numerical format specifiers. > > One solution could be to first print the millisecs to a buffer large enough > to hold MAX_INT. And then print that buffer as a string, which can be > truncated with precision. > > char tmp[10 + 1]; > snprintf(tmp, sizeof(tmp), "%d", millisecs); > snprintf(tbuf, ltbuf, "%s.%.3s %s", timestamp_date_time, tmp, > timestamp_timezone); > > That may be enough to shut the compiler up. What @tstuefe says makes sense and is the reason why the error messages are specific about how much the value might overflow. So really the following calculation isn't right in the theoretical case, but we know it is in practice: 47 #define MAXLEN_MS 5 // ".mmm " Since @coleenp fix seems to be working, this would be further proof that the issue lies here. I'm ok with the latest version of the fix, although it might be simpler to just update MAXLEN_MS to 10 ------------- PR: https://git.openjdk.java.net/jdk/pull/1067
