Your message dated Sat, 19 Dec 2009 03:03:27 +1030
with message-id <[email protected]>
and subject line Re: Bug#561599: Mingw32 snprintf broken
has caused the Debian Bug report #561599,
regarding Mingw32 snprintf broken
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
561599: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561599
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: mingw32
Version: 4.2.1.dfsg-1
Hi Ron,
See Werner's e-mail below. I believe it is possible to reproduce the
problem using this small code snippet:
j...@mocca:~$ cat>foo.c
#include <stdio.h>
int main (void)
{
char buf[1024];
int c = 65;
long d = 18;
int f = 42;
snprintf (buf, 1024, "foo %d bar %ld bee %d", c, d, f);
puts (buf);
}
j...@mocca:~$ gcc -o foo foo.c;./foo
foo 65 bar 18 bee 42
j...@mocca:~$ i586-mingw32msvc-gcc -o foo.exe foo.c;wine ./foo.exe
foo 65 bar 180388626450 bee 6422184
j...@mocca:~$
If my example is correct, this seems like a pretty severe bug to me
which may cause data corruption in programs built with this compiler.
Possibly the severity should be higher.
Thanks,
/Simon
Werner Koch <[email protected]> writes:
> On Fri, 18 Dec 2009 07:20:36 +0100, Simon Josefsson wrote:
>>
>> "Hoyt, David" <[email protected]> writes:
>>
>> >> If you want a makefile that does everything, check out
>> >> <http://*josefsson.org/gnutls4win/Makefile>.
>> >
>> > What version of gcc do you use (in the mingw toolchain)?
>>
>> I'm using the 'mingw32' package from debian, which appears to be gcc 4.2
>> based. http://packages.qa.debian.org/m/mingw32.html
>
> Take care: The mingw packages in Debian are broken:
>
> as GNU make. We are using Debian GNU/Linux (Lenny); due to a little
> bug in the mingw32 compiler it is highly suggested to put a line
> deb http://apt.intevation.org lenny/mingw .
> into /etc/apt/sources and update the mingw packages.
>
> they replaced the snprintf and introduced a bug. IIRC, "%lu" requires
> an "unsigned long long" arg and not an "unsigned long". The result is
> that the stack is messed up and you get all kinds of strange error.
> At one point it took us many hours of debugging until we realized that
> some parts of a system were build with the broken mingw runtime. The
> fix is trivial but still hasn't made it into Debian.
>
> I think libgcrypt does not use printf with "%lu" but that may depend
> on the version.
>
>
> Shalom-Salam,
>
> Werner
--- End Message ---
--- Begin Message ---
Hi Simon,
On Fri, Dec 18, 2009 at 04:17:43PM +0100, Simon Josefsson wrote:
> Package: mingw32
> Version: 4.2.1.dfsg-1
Wrong package. This is an issue in the runtime library, not the compiler.
#452977 is the bug you want, and it's already 'important'. So I'm going
to -done this one, just because there is already a fairly concise summary
there, and merging this would just duplicate that for anyone else trying
to come up to speed on the situation.
I do confirm that it's real and known though. However ...
> Werner Koch <[email protected]> writes:
> > Take care: The mingw packages in Debian are broken:
> > ...
> > they replaced the snprintf and introduced a bug.
... I have no idea why Werner spouts nonsense like this now though.
Given his comments in #452977 it seemed pretty clear he was aware this
was an upstream bug, and best fixed (along with several of its other kin)
by pulling in a new upstream release. The message at:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=452977#20
was a direct reply to him pointing at part of the upstream explanation.
But *shrug*. One of the main things I really need to know right now before
we can think about bringing in the new upstream, is whether or not the
licence issues that were raised for gcc 4.4 are an issue for this package
(since a 4.4 derivative is the next upstream release).
I haven't really had a straight-faced answer on that from anyone yet, and
it would be nice to get one before I replace the existing toolchain, that's
currently working for quite a few people, with something they may not legally
be able to actually use. That's a separate issue to this bug, but one of
the things that is logically blocking it in practice right now.
If you do have any real new info on _this_ bug, please do attach that to
#452977, but I think we've about covered all but actually getting the new
upstream in over there already.
Cheers,
Ron
--- End Message ---
