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

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

christos%astron.com@localhost (Christos Zoulas) wrote:
 |In article <20140929201300.a8ENWnx3%sdaoden%yandex.com@localhost>,
 |Steffen Nurpmeso  <sdaoden%yandex.com@localhost> wrote:
 |>And, finally:
 |>
 |>|Log Message:
 |>|Return EOVERFLOW like FreeBSD does if the buffer size exceeds INT_MAX
 |>|(well FreeBSD documents INT_MAX + 1, but in the code it is INT_MAX).
 |>
 |>hm, ok, yes S-nail without the fix doesn't print the Message-Id:
 |>even on FreeBSD, but at least the buffer is terminated at [0] and
 |>thus no binary garbage is printed when the buffer is printed.
 |>Ciao,
 |
 |I am not sure if it is a good idea to touch the buffer when returning
 |an error.

What if EOVERFLOW occurs because buffer space runs out after
processing say 1000 bytes.  And here there is buffer space
available: the buffer is too large.  What a shitty error
condition, imho.

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
implemented; of course i personally would NEVER implement grazy
shit like STD I/O, i have implemented nice context-carrier classes
for this problem, which is the only sane approach; and now that
i know Plan9 i'm no longer alone with this good stuff :-).  Hmm.
(Haha).

But the problem is that the return values are int whereas the
buffer size is size_t, the prototypes should at least go for
a ssize_t return but that of course is not ISO C.
But then again: ISO C is plain grazy!
How often do i see patches flying by where memory of an object is
temporarily copied to aligned data on the stack only to be able to
not run into undefined behaviour.  Plain overengineered shit.
Of course you can terminate a buffer that is UI32_MAX bytes.

--steffen