Hacker News new | past | comments | ask | show | jobs | submit login

"Opening this image in Firefox at various different times, it has show up as shades of blue, green and brown"... That seems like odd behavior - does anyone know why this would be the case? Is it different stack values at the time?



Possibly Firefox doesn't clear the memory used to draw the image, assuming all will be filled. So different stack or heap values.

It could also be re-using a drawing surface of some sort.


I don't think that's it -- I'm not sure where I saw this, but I believe it's because if there's no global color table in the image, the spec says the displaying software should supply one... but there's no standard color table, so Firefox substitutes the color table from the last image it displayed. With asynch loading that can vary.

If that's not right, maybe it's supplying a color table randomly-generated on the fly, but I doubt it's just random memory -- can any random bytes really make up a valid color table? If it were random memory I'd expect crashes or errors, not varying colors.


All a color table is is a series of integers. Any random byte, or two, or four, is a valid integer.


Have you ever done any C programming? malloc() returns a pointer to an allocated block, but it isn't zeroed for you, so if you don't clear it yourself you may end up with random data. Same with uninitialised variables in C.


I have; but I was talking about whether the Mozilla devs, given no color table in a GIF, assume they actually found one and stored it to a memory location, or handled the case as correctly as they could (by initializing the memory with a replacement color table).

It's a programming error if they assume the earlier code found an (optional) color table; that's it.

I didn't know the color table was formatted -- kinda obviously, it's just a 3-byte chunk per color, though (i.e., 00ffaa) so any bytes in there will be valid colors... so my original idea that random memory would crash things (by providing an invalid color table) was wrong.


You may assume too much here. The code may simply assume a colour table has been populated along the way. There might not even be a check for there being no global colour table or frame colour table.


That's exactly what I'm saying -- that may well be the case (and that would be a coding error), or maybe they coded some handling; we can't tell from the results (varyingly-colored pixels in the displayed result).


Seems like it could lead to information disclosure




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: