[REBOL] Re: explanation, gurus? :-) (image memory representation)
From: jeff:rebol at: 21-Aug-2001 7:10
Howdy, DocKimbel:
> > What about this one?
> >
> > img: make image! [10x10 #{FFFFFF}] == make image! [10x10
> > #{
> > FFFFFFCC96CFD8A9CD0000000A00004C96CFE8B0CD0000000A00001C90CF
> > E8B0CD0000000A0000C4E3D9E8B0CD0000000A000084E...
>
> That's clearly a bug. The byte sequence that appear is a
> Rebol memory space dump !! It's more than a simple bug,
> it's a potential security hole !
When we create an image and pass in some binary data to use
for that image: if the image is larger than the data we
provided the remaining memory is uninitialized. This memory
is from the heap. No live objects will be in there, but
perhaps fragments of recycled objects could be evident
there. It'd be hard for someone to programmatically exploit
this current behavior by looking a random window of heap
memory because the contents are as good as random due to the
variances in the recycling path for different OSes,
architectures, and machine configurations-- this is also not
an issue of a being able to munge the stack since this is
all heap memory (possibly reclaimed or otherwise).
Nonetheless, this remainder memory should be cleared.
> Also, did you notice that image!'s data are stored
> internally in 32 bits ?
We save out images with out the alpha channel and reconstruct
the alpha channel when reading images back in.
> It would be great if more Rebol types were supported by the
> /library interface. (Image! should be my first choice!).
The next Library revision will allow all string-series! types
to be passed where a library routine expects string!-- that
includes such types as image, binary, issue, email, etc.
RETURING these types is a whole different issue, though. :-)
-jeff
