Re: Please consider scmxx_0.7.5-2 for sarge
Hi,
On Wed, May 18, 2005 at 08:15:16PM -0700, Steve Langasek wrote:
> On Wed, May 18, 2005 at 01:49:53AM +0200, Michael Banck wrote:
> > I included the patch provided by him in 0.7.5-2, please consider it for
> > inclusion in Sarge.
>
> Could you explain how exactly this is an architecture-specific bug? It's
> not at all obvious from the patch.
As I am not thoroughly intimate with the scmxx code (...), I asked the
upstream maintainer to elaborate on this. This is what he said:
| A user contacted me (the author) with the problem he did not have with
| scmxx-0.7.4 but with scmxx-0.7.5 about decoding some SMS. He used a
| PPC linux distribution (not sure if it's debian) and I simply could
| not confirm the bug with my AMD Athlon system (else I would have fixed
| it before release). However, I believed him and was able to reproduce
| it on my Sparc32 system (SS20 clone) running Debian Sarge.
| The problem affects the gsm_chars array in src/charsets/gsm.c due to
| linking order (charsets.o just happens to be after options_getopt.o).
| That struct then appears to be empty at run time because of this bug
| in src/options_getopt.c (and src/options_popt.c). The bug itself
| writes beyond struct args_def args_list[] from src/options.c and
| actually to the wrong struct. Instead it should write the final
| element to the end of the dynamically created list. This struct is
| used to create the getopt and popt structs at runtime from a unified
| list. That the list end condition still matched made it even trickier
| to locate the bug.
| I guess that due to alignment that it affects only some architectures
| (might be compiler specific, don't know). You could also change the
| linking order but the real fix should be prefered.
| In short words: self-rewriting code, it was, but not the intention of
| the author to have such.
cheers,
Michael
--
Michael Banck
Debian Developer
mbanck@debian.org
http://www.advogato.org/person/mbanck/diary.html
Reply to: