[Bug#64801] URGENT: Please evaluate this easy fix enabling wxgtk2.1 to build!
NOTE: the bug in question is filed as Bug#64801; please comment to that
bug report and to -devel (if still appropriate to do so).
> Date: Sat, 27 May 2000 19:28:49 EDT
> To: Jim Lynch <email@example.com>
> cc: firstname.lastname@example.org
> From: Mike Bilow <email@example.com>
> Subject: Re: URGENT: Please evaluate this easy fix enabling wxgtk2.1 to build!
> No, this is a _feature_ of C++, not a bug. The signature of a function is
> defined by its argument types, and C++ regards two functions with the same
> name but different signatures as two different functions. In standard C,
> you would get the same function, but a silent cast might occur.
I agree with this; the fault is with wxwin. I would have filed against
c++ if I didn't believe that.
> Whether bare 'char' defaults to 'signed char' or to 'unsigned char' is
> implementation dependent, however. Most likely, if this got through from
> upstream, it was because the upstream maintainer's implementation assumed
> 'signed char' in this case.
Which probably should not be, imo. If it's an incoming string that the
called fn will not be changing, then const char * should always be used.
> Most machines are more efficient when handling unsigned values than signed
> values, while a few machines are more efficient when handling signed
> values than unsigned values. If the program is limited to being compiled
> with gcc anyway, then the behavior of the the compiler can be changed with
> the '-fsigned-char' switch. The gcc default is to use whichever mode is
> more efficient for the target platform.
Then wxwin should be self consistant. In any case, the package will not
build from source without this patch or something like it.
Jim Lynch Finger for pgp key
as Laney College CIS admin: firstname.lastname@example.org http://www.laney.edu/~jim/
as Debian developer: email@example.com http://www.debian.org/~jwl/