Re: snprintf(3) behaviour regarding large "n"

[Steffen Nurpmeso <sdaoden%yandex.com@localhost>]

David Holland <dholland-tech%netbsd.org@localhost> wrote:
 |On Mon, Sep 29, 2014 at 09:49:18PM +0200, Steffen Nurpmeso wrote:
 |> I just looked at OpenBSD now -- they clamp to INT_MAX if >INT_MAX,
 |> which is a much more sane approach that i would also have

 |Problem with that is that there's a lot of code that checks if the
 |return value is less than the max size to see if the string (didn't)
 |get truncated. So if you clamp the max size, this logic breaks.

Does the function stop processing and return EOVERFLOW if the
result would exceed that "int" that is used for the return value,
i.e. the actual buffer size?
If so, i think you are creating an artificial problem.

 |anyway, this seems like a theoretical problem - are you really
 |snprintf'ing into a 2GB buffer?

I think you're right with that.
(A different I/O would be fine, but i cannot imagine it will get
around the unsigned argument / signed return discrepancy.)

P.S.: this snippet flew by when i (git) grep'ed in usr.bin for
      snprintf(3) usage (gzip/gzip.c) and isn't multibyte safe.
      Shall i open a bug report?

                /* Add (usually) .gz to filename */
                if ((size_t)snprintf(outfile, outsize, "%s%s",
                                        file, suffixes[0].zipped) >= outsize)
                        memcpy(outfile + outsize - suffixes[0].ziplen - 1,
                                suffixes[0].zipped, suffixes[0].ziplen + 1);

--steffen