Re: [lmi] Upgrading wx: ellipsis buttons, and wxUSE_STACKWALKER

[Vadim Zeitlin]

On Thu, 9 Jun 2016 14:57:01 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2016-06-09 14:04, Vadim Zeitlin wrote:
GC> 
GC> > and what possible harm can they do? I just don't see it.
GC> 
GC> Neither of us sees it, but our reasons differ. You don't see it because
GC> you know exactly what they do, and know that no harm can ensue. I don't
GC> see it because I know only that 'configure' used to disallow them, so I
GC> assumed they were dangerous, and why would I step into unknown danger?

 Sorry, but I'll just have to disagree with this paragraph as this is not
how configure works. It doesn't disallow anything, unless you explicitly
ask it to, it just disables the features which can't work in the current
configuration. I.e. the fact that configure detected lack of support for
some feature FOO is absolutely not an indication that FOO is dangerous in
any way! Most likely, it just means that libfoo is not installed on the
current system, that's all.

 Whatever the danger of using FOO, it shouldn't be affected by configure
detection at all. If you consider it dangerous, you need to explicitly
disable it with the appropriate configure command line option
(--disable-foo or --without-foo). If you don't, there is nothing to do.

 Notice that disabling all optional features except those you're sure to
use is not a good idea neither because it increases the likelihood of
running into bugs not present in the default version with all features
enabled. Of course, bugs are not supposed to happen, but, even more of
course, they do. And I'm not at all sure that the tiny gains from disabling
wxUSE_THREADS, for example, outweigh the very real danger of running into
some issue that nobody else will have ever seen nor reported because
everybody does use threads nowadays and so this option is almost never
disabled in practice and builds without it are never tested.


GC> I believe I have a robust workaround for perceived shortcomings of
GC> wx-2.5.1 built with gcc-2.95 . Maybe that's no longer needed, but I'm
GC> not going to remove carefully written and tested code without new
GC> careful testing, which would take time.

 I also disagree with this (keeping old code unchanged may and will result
in problems too), but I don't have anything new to add to what I had
already written before, so let's skip this...


GC> So we'd get a stack trace if lmi crashes?

 Well, almost. I actually tested this wxWidgets change with lmi, after
disabling the overridden OnAssertFailure(), so I know that it does work,
but it's not as nice as with MSVC because gcc doesn't emit debug
information in the platform-standard PDB format, but you get at least the
addresses, which is better than nothing, and could be used with addr2line
(and I even thought about integrating support for this in wxWidgets
itself), and you can also use https://github.com/rainers/cv2pdb tool to
convert DWARF debug info (which is more or less the same as CodeView
format) to PDB and then you do get the real symbolic information. I did run
into bugs with cv2pdb tool and I'm not sure how wise is it to rely on it,
so I feel like addr2line approach could be a better one, even if it relies
on an external program. Anyhow, further improvements are definitely
possible, but what we have now is already better than nothing. And there
is, of course, 0 danger in having this code in wxWidgets as long as lmi
doesn't use it in any way anyhow.

 Regards,
VZ