This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: Bug in Newlib's snprintf implementation
- From: Sebastian Huber <sebastian dot huber at embedded-brains dot de>
- To: Dominik Maier <domenukk at gmail dot com>
- Cc: newlib <newlib at sourceware dot org>
- Date: Fri, 23 Feb 2018 04:34:35 +0100 (CET)
- Subject: Re: Bug in Newlib's snprintf implementation
- Authentication-results: sourceware.org; auth=none
- References: <2087785f-7d49-3a2d-38f5-cb7d17908fa3@gmail.com>
----- Am 23. Feb 2018 um 4:00 schrieb Dominik Maier domenukk@gmail.com:
> Hello,
>
> I've already reported this over at MinGW but since I could also
> reproduce the Bug in Cygwin and understand both use Newlib, I figured
> I'd post this here, too.
>
> The snprintf implementation is not compliant. This can lead to bugs and
> memory corruptions.
>
> A simple PoC is the following
>
> char buf[4];
> snprintf(buf, 4,"te%s", "st");
> printf("%s", buf);
>
> It should print "tes" (0-terminated) but instad prints "test" and
> appends random memory (tested in cygwin and mingw).
>
I cannot reproduce this issue on RTEMS. Her buf is "tes\0" and the return value is 4.
> Then len field in this case is 4, which is correct (apart from the
> missing zero termination), however it will return an error (-1) for any
> larger input.
It should return the actual size of the produced string and not -1.
>
> The original MinGW bug report is here:
> https://sourceforge.net/p/mingw-w64/bugs/709/
>
> Best
>
> Dominik