From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <sourceware-bugzilla@sourceware.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 0C2703858426; Thu, 11 May 2023 21:41:07 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0C2703858426
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org;
	s=default; t=1683841267;
	bh=qgy001mq6665clat3YAFfdeDwtfRBwKGkY8RWc3RM4Q=;
	h=From:To:Subject:Date:From;
	b=Ffzf0tBzozyklj8+/GcxuoSRdtc3gBmKSuiAUrDpyTs62PczMP4VVwaUrZtB+onzh
	 v3+iKPAcU2G4Q4NyZyglinUpQMLGHa2GSrErQ5Hef2vRjY/WHItUv4PLgoSHAGD9hz
	 RbMBMkhuadTdCj71mtdDVU782abwa46lbqG/4kvw=
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
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.37
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: gabravier at gmail dot com
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: <bug-30441-131@http.sourceware.org/bugzilla/>
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
List-Id: <glibc-bugs.sourceware.org>

https://sourceware.org/bugzilla/show_bug.cgi?id=3D30441

            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] =3D {};

    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=20
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 chose=
n 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))

--=20
You are receiving this mail because:
You are on the CC list for the bug.=