On Thu, 5 Nov 2020 18:22:56 GMT, Thomas Stuefe <stu...@openjdk.org> wrote:
>>> I don't think this is the case. If you assume the arguments are not null >>> terminated, then there is no limit to how long the string could be, >>> where-as the error messages are very specific with the (incorrectly) >>> calculated range of potential overflow. >> >> I must be missing what you're suggesting here? > > 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. ------------- PR: https://git.openjdk.java.net/jdk/pull/1067
