Re: ProFTPD 1.2.0pre4 available

[casper () HOLLAND SUN COM (Casper Dik)]

> Yes, people should be really careful about this.
>
> - The 4.4 BSD snprintf routines were mostly right before, and now
>  they are even better.  I can only speak for OpenBSD.

Which snprintf() function originally returned "n" where n was at most
"size - 1"?  That was the original specification (but it was quickly determined
to be less useful than the current definition)

> - The older Solaris versions are broken.

There is no "older" Solaris version; there's the undocumented __snprintf()
which was implemented in libc patches; it works differently.

> - The newer Solaris versions are wrong (7+?).

AFAIK, it's only wrong when called with n = 0 (The behaviour XPG4 calls
undefined)

> - The opengroup XPG web documentation is wrong.
> - But the opengroup group internal documentation is fixed (we believe)
> - Older C9X specifications are wrong.
> - Newer versions of the C9X specification are fixed (we believe)
>
> Casper Dik, Todd Miller, Chris Torek, and I got in touch with the
> standards commitees and got it fixed.  The fixed versions return the
> amount of data they wanted to put into the string, even if they fail.
> The broken versions returned -1 or the truncation length.  A few other
> issues regarding -1 return values also existed.

Standard snprintf can still return -1, I believe.  I think this was
true according to C9X  as well as XPG4.  The errors that
can be returned:

     EILSEQ
            A wide-character code that does not  correspond  to  a
            valid character has been detected.

     EINVAL
            There are insufficient arguments.

The former is listed in C9X, the latter is present in XPG4, though it
beats me when they detect this.

On a quick scan of the manual page, it appears that this can only happen
in the presence of %lc, %wc, %ls, %ws, (%C, %S) formats.

The EINVAL return value points to a programming error, so it shouldn't
be much of a problem.

If C9X does not list EILSEQ for snprintf and still lists it for the
rest of the *printf family, there an orthogonality problem.

Since both error codes appear to be avoidable by chosing the argumens
and format string properly, I don't see much of a problem.

Once C9X and XPGn have settled down, we'll fix Solaris snprintf() to be
standards conforming.  (Which, as things stand now, if fixing the n = 0
behaviour)

Casper