From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E2F39385383F; Wed, 12 May 2021 20:16:52 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E2F39385383F From: "warp at iki dot fi" To: glibc-bugs@sourceware.org Subject: [Bug stdio/27857] New: swprintf does not output a null character when output would be too long Date: Wed, 12 May 2021 20:16:52 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: stdio X-Bugzilla-Version: 2.33 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: warp at iki dot fi X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: glibc-bugs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-bugs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2021 20:16:53 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D27857 Bug ID: 27857 Summary: swprintf does not output a null character when output would be too long Product: glibc Version: 2.33 Status: UNCONFIRMED Severity: normal Priority: P2 Component: stdio Assignee: unassigned at sourceware dot org Reporter: warp at iki dot fi Target Milestone: --- Consider this behavior of swprintf: //---------------------------------------------------- #include #include int main() { wchar_t buffer[8] =3D { 1, 2, 3, 4, 5, 6, 7, 8 }; int retval =3D swprintf(buffer, 4, L"abcdefg"); printf("%i: { %02X", retval, buffer[0]); for(unsigned i =3D 1; i < 8; ++i) printf(", %02X", buffer[i]); printf(" }\n"); } //---------------------------------------------------- In all systems I have tried (various Linus distros, and various versions of both gcc and clang) it will print this: -1: { 61, 62, 63, 04, 05, 06, 07, 08 } which means that it prints the first 3 characters of the string, as it shou= ld, but does not output the null character as the fourth element. This makes it different from snprintf, which does output the null character regardless of whether the destination is too short or not. (The return value of -1 is concordant with the C standard in this case.) Reading the glibc documentation I get the impression that this is deliberat= e, not just a bug or oversight. I get the impression that glibc chooses to sig= nal "failure" with the return value of -1, failure in the sense of "the output = is invalid and should not be assumed to be anything particular" (or the like). However, reading the C standard, I don't see it giving implementations permission to not write the ending null character, which I would argue means that glibc is not standard-conforming in this regard. The standard says: "The swprintf function is equivalent to fwprintf, except that the argument s specifies an array of wide characters into which the generated output is to= be written, rather than written to a stream. No more than n wide characters are written, including a terminating null wide character, which is always added (unless n is zero)." And: "The swprintf function returns the number of wide characters written in the array, not counting the terminating null wide character, or a negative valu= e if an encoding error occurred or if n or more wide characters were requested t= o be written." I don't see anything in this text that would suggest that an implementation= can refuse to write the first n-1 characters of the string-to-be-printed plus a null character ("which is always added"), even if the return value will be = -1 because n was too small. It would make it concordant with the behavior of snprintf (which the standard more clearly defines as printing at most n-1 characters plus the null character even if n is too small to contain the en= tire output.) The different behavior of swprintf and snprintf can be inconvenient because they are not directly interchangeable with each other (eg. using conditional macros). --=20 You are receiving this mail because: You are on the CC list for the bug.=