public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug stdio/27857] New: swprintf does not output a null character when output would be too long
@ 2021-05-12 20:16 warp at iki dot fi
  2022-03-17 18:33 ` [Bug stdio/27857] " fweimer at redhat dot com
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: warp at iki dot fi @ 2021-05-12 20:16 UTC (permalink / raw)
  To: glibc-bugs

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.

^ permalink raw reply	[flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-08-15 10:35 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-12 20:16 [Bug stdio/27857] New: swprintf does not output a null character when output would be too long warp at iki dot fi
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

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).