public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "gabravier at gmail dot com" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sourceware.org Subject: [Bug stdio/30441] New: snprintf truncates output on extremely large buffer sizes Date: Thu, 11 May 2023 21:41:06 +0000 [thread overview] Message-ID: <bug-30441-131@http.sourceware.org/bugzilla/> (raw) https://sourceware.org/bugzilla/show_bug.cgi?id=30441 Bug ID: 30441 Summary: snprintf truncates output on extremely large buffer sizes Product: glibc Version: 2.37 Status: UNCONFIRMED Severity: normal Priority: P2 Component: stdio Assignee: unassigned at sourceware dot org Reporter: gabravier at gmail dot com Target Milestone: --- #include <stdio.h> #include <stdint.h> int main(void) { char buf[100] = {}; printf("snprintf: %d \nbuf: %s\n", snprintf(buf, SIZE_MAX, "test"), buf); } Compiling this program with: $ gcc -ggdb3 test.c -o glibc and then running it with: $ /tmp/tmp.qoS3ELDYbg/testrun.sh ./glibc outputs: snprintf: 4 buf: tes I believe this is not conforming behavior, as although the provided buffer size is larger than the buffer, snprintf should not be affected (i.e. I would not expect the program to be considered to be invoking undefined behavior) as it should only write as many characters as required by the formatted string. As such, writing "tes" (truncating the buffer for no reason) is not conforming behavior, as the provided buffer was large enough to contain the formatted string "test". (PS: Looks like POSIX says this call should result in EOVERFLOW, which libcs like musl do, but looking at previous discussion it appears glibc has chosen to disregard this - I'd doubt the intent was to randomly truncate strings when given massive buffer sizes, though) Tested on: $ /tmp/tmp.qoS3ELDYbg/libc.so.6 | head -n1 GNU C Library (GNU libc) development release version 2.37.9000. (note: I initially found this on my Fedora laptop with glibc 2.37, but was able to reproduce it on recent trunk (specifically commit d6c72f976c61d3c1465699f2bcad77e62bafe61d)) -- You are receiving this mail because: You are on the CC list for the bug.
next reply other threads:[~2023-05-11 21:41 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-05-11 21:41 gabravier at gmail dot com [this message] 2023-05-11 21:46 ` [Bug stdio/30441] " gabravier at gmail dot com 2023-05-12 0:09 ` michael.hudson at canonical dot com 2023-05-12 0:45 ` gabravier at gmail dot com 2023-05-14 21:29 ` michael.hudson at canonical dot com 2023-06-06 21:50 ` gabravier at gmail dot com 2023-06-07 1:53 ` gabravier at gmail dot com 2023-06-07 8:39 ` sam at gentoo dot org 2023-06-07 23:09 ` joseph at codesourcery dot com 2023-07-25 21:59 ` nbowler at draconx dot ca 2024-01-17 9:32 ` schwab@linux-m68k.org 2024-01-17 19:47 ` i at maskray dot me
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-30441-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).