public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "warp at iki dot fi" <sourceware-bugzilla@sourceware.org> 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 [thread overview] Message-ID: <bug-27857-131@http.sourceware.org/bugzilla/> (raw) https://sourceware.org/bugzilla/show_bug.cgi?id=27857 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 <wchar.h> #include <stdio.h> int main() { wchar_t buffer[8] = { 1, 2, 3, 4, 5, 6, 7, 8 }; int retval = swprintf(buffer, 4, L"abcdefg"); printf("%i: { %02X", retval, buffer[0]); for(unsigned i = 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 should, 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 deliberate, not just a bug or oversight. I get the impression that glibc chooses to signal "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 value if an encoding error occurred or if n or more wide characters were requested to 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 entire output.) The different behavior of swprintf and snprintf can be inconvenient because they are not directly interchangeable with each other (eg. using conditional macros). -- You are receiving this mail because: You are on the CC list for the bug.
next reply other threads:[~2021-05-12 20:16 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-12 20:16 warp at iki dot fi [this message] 2022-03-17 18:33 ` [Bug stdio/27857] " fweimer at redhat dot com 2022-12-19 18:56 ` cvs-commit at gcc dot gnu.org 2023-08-15 10:35 ` fweimer at redhat dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-27857-131@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).