On Sat, 16 Jun 2001, Christoph Reichenbach wrote:
> On Sat, 16 Jun 2001, Matt wrote:
> > The function graph_map_ega_color() appears to read uninitialized memory
> > (at kgraphics.c:223).
>
> Yes. The values it reads there are 'dont-care' values. Colors have a
> bitmask determining whether their visual/priority/control values are set;
> if the bitmask says "this value is not relevant", then the contents of the
> corresponding field entry can be disregarded (see gfx_system.h) and are
> not set explicitly (the correct value to set them to would probably be
> semi-random numbers, to expose places where these values are being used
> regardless).
Ok. Could we initialize them to a value that would allow us to see when
they're being used? This is mostly to eliminate these warnings so when
problems are detected they don't get buried in the flood (similar to
compiler warning elimination) :) Would doing this cause any real
performance problem?
> > 1) Line 277 and 282. Only the first 3 ints in the 4 int array would be set
> > to 0 by the memset operation.
>
> That's because the fourth value is explicitly set to a different value in
> the next line.
d'oh, sorry. It was very late when I was looking at these things.
> > 2) When the case is the last "else if" (transparent) in
> > gfx_get_pixel_delta, only the 3rd int the the delta array is initialized.
> > All the other ints will be uninitialized. So, when gfx_apply_delta is
> > called, uninitialized memory is read.
>
> Yes. The idea behind this is that, if it's completely transparent, we
> don't really have to care whether it's transparent blue or transparent
> octarine.
Ah.... I see now. Once again, it would be useful to set these to values to
something that would let us know when they are being used improperly, and
eliminate the warnings.
> > I don't know what this should be initialized to, as this code is kind of
> > over my head (maybe more comments?) so this fix is not included in my
> > patch.
>
> I have to admit that the basic ideas behind it are not explicitly
> stated anywhere in the code; particularly an explanation of the actual
> algorithm is missing. A functional description of the algorithm (though
> obviously not of this particular implementation) can be derived from the
> official OpenGL specification.
Actually, looking at it now that I'm fully awake it does make sense. I was
just very tired, sorry for the confusion.
> The piece of information you were probably missing (indicated, but never
> explicitly stated in lines 348, 352 and 305) is that the four-tuples we're
> using all over the place contain red, green, blue, and alpha values at
> indices 0, 1, 2, and 3 respectively. All values are stored as 24 bit
> values (actually, they should also work OK as 32 bit values, with
> appropriate changes, but I can't think of any reason to change this ATM).
Surprisingly, that was the one thing I did understand ;> I was talking
more about the main function, FUNCNAME_TRILINEAR.
Thanks for being constructive :)
--
http://www.clock.org/~matt
