>Hi there,
>
>I currently am updating some programs used to visualize factory floor
>process information at our site from 0.89.9 to 0.91.4. During that I
>came to some minor changes I had to do, to get these running stable.
>
>A patch file for vanilla 0.91.4 is included. Here are the main areas
>I touched, and some reasoning about them:
>
>1. lib/Xm/List.c
> Performance gains while updating undisplayed items. I checked this
> very seriously and didn't find any argument against it. It removes
> nearly all flicker while updating large lists (that are mostly off
> screen) and it is fairly small change.
Idea sounds reasonable to me ...
Hmm, doesn't apply on my current cvs version, I should try
with a more recent version of patch perhaps.
>2. lib/Xm/Text.c
> ensure that subscripts are valid (even though they should already
> be, our programs manages to core dump occasionaly here). Adding some
> trivial tests, that have no real impact on performance but make
> (at least our) programs a lot more stable.
I can't follow here.
In my understanding of the code it is _impossible_ to end up with
i <= 0 in the line
Text_Line(w)[i - 1].changed = True;
My conclusion would be therefore that the error is not "here".
(see below)
Did you a) debug on a non-optimized executable and/or
b) have a powerful system to run a malloc checker on the
app?
>3. lib/Xm/String.c
> ensure memory gets freed only if it has been allocated. This seems
> to be a rare event, but sometimes it crashes our programs. The check
> is trivial, and no real impact on performance was seen.
Haven't looked here in detail, also smells a bit like
a "bug_but_not_here" as above. This means having a bug within
LessTif which causes both is not very unlikely, but I'm just
not sure they are where you "fixed" them ...
Bye,
--
Alexander Mai
[EMAIL PROTECTED]
