Bug in Newlib's snprintf implementation

[Dominik Maier]

Hello,

After retesting, I can confirm this issue only exists inside mingw-w64-crt.
Newlib is not affected!
Not having used Cygwin for years I assumed it would "do the right thing"
after installation, however it picked up the gcc of Strawberry Perl
(apparently mingw-w64 based) from $PATH instead of the Cygwin gcc.

Additional background for the insterested: Mingw-w64-crt forwards calls
to an older Microsoft _vsnprintf function with deviating semantics [1].

I am terribly sorry for the false bug report and hope I did not cause any
trouble.

Best

Dominik


[1] https://msdn.microsoft.com/en-us/library/1kt27hek.aspx

Sebastian Huber <sebastian.huber@embedded-brains.de> schrieb am Fr., 23.
Feb. 2018 um 04:32 Uhr:

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