Your message dated Sun, 30 Apr 2006 14:00:39 +0930
with message-id <[EMAIL PROTECTED]>
and subject line Bug#344242: sorry, fixed and waiting on NEW processing
has caused the attached Bug report 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 I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Package: wxwidgets2.6
Version: 2.6.1.2
Debian package of WxWidgets v2.6.1.2 on AMD64 Linux
WxWidgets has its own regular expression library. Among other things, this
library defines the function regfree(). This directly conflicts with the
POSIX regfree() which is provided by libc on Unix platforms. As a result,
it is possible to get into a situation where an application (perhaps one
linking with a 3rd party library or plugin) links to regcomp() and
regexec() provided by libc, but regfree() provided by WxWidgets. This
causes a crash because the WxWidgets regfree() is obviously not compatible
with the libc regcomp().
I can see no good reason for the implementation of regfree() within
WxWidgets to be named that way. Anyone using regular expressions in
WxWidgets should be doing so via the WxWidgets C++ class. The obvious fix
is to simply rename regfree() to something that won't cause a conflict,
such as wx_regfree().
Bug report has already been filed upstream with the proposed fix (attached
patch).
[ Peter Amstutz ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDqMZ5aeHUyhjCHfcRArO6AKCp6HyhlxAw1TmKrV2qfdAaJnb1pQCfQx8k
lNWTKwSAhR6U6RD1OYtEWMQ=
=gs5p
-----END PGP SIGNATURE-----
diff -ruw wxwidgets2.6-2.6.1.2/src/common/regex.cpp
wxwidgets2.6-2.6.1.2-regfreefix/src/common/regex.cpp
--- wxwidgets2.6-2.6.1.2/src/common/regex.cpp 2005-08-25 08:52:18.000000000
-0400
+++ wxwidgets2.6-2.6.1.2-regfreefix/src/common/regex.cpp 2005-12-20
21:30:25.000000000 -0500
@@ -89,7 +89,7 @@
{
if ( IsValid() )
{
- regfree(&m_RegEx);
+ wx_regfree(&m_RegEx);
}
delete [] m_Matches;
diff -ruw wxwidgets2.6-2.6.1.2/src/regex/regex.h
wxwidgets2.6-2.6.1.2-regfreefix/src/regex/regex.h
--- wxwidgets2.6-2.6.1.2/src/regex/regex.h 2005-08-25 08:52:04.000000000
-0400
+++ wxwidgets2.6-2.6.1.2-regfreefix/src/regex/regex.h 2005-12-20
21:30:58.000000000 -0500
@@ -254,7 +254,7 @@
/*
* misc generics (may be more functions here eventually)
- ^ re_void regfree(regex_t *);
+ ^ re_void wx_regfree(regex_t *);
*/
@@ -318,7 +318,7 @@
#ifdef __REG_WIDE_T
int __REG_WIDE_EXEC _ANSI_ARGS_((regex_t *, __REG_CONST __REG_WIDE_T *,
size_t, rm_detail_t *, size_t, regmatch_t [], int));
#endif
-re_void regfree _ANSI_ARGS_((regex_t *));
+re_void wx_regfree _ANSI_ARGS_((regex_t *));
extern size_t regerror _ANSI_ARGS_((int, __REG_CONST regex_t *, char *,
size_t));
/* automatically gathered by fwd; do not hand-edit */
/* =====^!^===== end forwards =====^!^===== */
--- End Message ---
--- Begin Message ---
Hi,
On Sun, Apr 30, 2006 at 11:37:21AM +0800, Lalo Martins wrote:
> Sorry to be a bother Ron, but you can't close the bug until it's fixed
> ON DEBIAN.
>
> >From http://www.debian.org/Bugs/Developer
> <http://www.debian.org/Bugs/Developer> : "Problems in packages can
> only be considered fixed once a package that includes the bug fix
> enters the Debian archive." What you *can* do is tag it with the
> "fixed-upstream" tag.
>
> Specially since it was "fixed upstream" more than 4 months ago, but
> not only there are no .debs yet, we don't even know when there will be
> one -- so it's really deceptive to close the bug.
If you'd have checked a little more, you should have seen it's
presently waiting on NEW processing. So we still don't know
"when there will be one", but since its out of my hands now,
and won't be closed by the changelog when it does make it
through, I'm restoring that status manually again now.
Sorry for the delay, if I'd anticipated how far away a viable
new upstream really was, I may have treated this differently
at the time and left it pending or looked at backports for
individual issues. I hope to be able to address this sort of
thing far more easily in the near future.
cheers,
Ron
--- End Message ---
