[PATCH] statistics.c: Fix a potential compiler bug triggered in gcc 3.4.5

[Lubomir I. Ivanov]

On 23 February 2013 18:19, Dirk Hohndel <dirk at hohndel.org> wrote:
> "Lubomir I. Ivanov" <neolit123 at gmail.com> writes:
>> please mind that i'm perfectly ok with this not being included, still i think
>> it should be or at least i would include fixes like that. my reasoning is that
>> if someone decides to use said compiler (which is unlikely) and statistics.c
>> haven't changed much he will definitelly encounter that bug and i will then
>> have to waste time explaining the issue again.
>
> Can I get another version of this patch with the compiler version /
> platform / OS included in the commit message, please?
>

just sent an update.

>> the obvious fix is to send patch to the gcc folks, but i hardly believe anyone
>> maintains this 6y/o version anymore.
>
> Right
>
>> again, if the patch is NACK-ed, i will probably just write a SED script
>> for my own needs and i'm good to go. :)
>
> Have you checked if there are other places in the source that use the
> same construct?
>

grep "++]" *.c -rn
cochran.c:39:           unsigned char d = decode[offset++];
profile.c:1697: plot_data[idx++].sec = lasttime+10;
profile.c:1698: plot_data[idx++].sec = lasttime+20;
save-xml.c:217: buffer[len++] = ' ';
save-xml.c:219: buffer[len++] = '\'';
save-xml.c:246:         buffer[len++] = '>';
uemis.c:57:                             v = inbuf[indx_in++];
uemis.c:73:                             outbuf[indx_out++] = out[i];

shows these occurrences, but i don't think i've encountered an error
in there. then again i cannot really test cochran.c or uemis.c unless
i have these devices, i'd think...
uemis.c seems suspicions, since this bug might actually be a "nested
loops with list[idx++] inside" thing.
on the other hand it literally can depend on 100 conditions for it to
be triggered, which makes it potentially notorious to debug on
compiler level.

lubomir
--