You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The following program prints EOF, which looks weird (whole image decoded?). Jpeg and png print UnexpectedEOF in this case. Gif should also return UnexpectedEOF.
This is easy to just do, but it is hard to know how far to take it. If the header is OK, but there are no bytes after it, then we'll get EOF from someplace else. If there's one byte indicating we should go into readExtension, but no more, then readExtension needs the code change too.
Anyway, I'm posting a CL that fixes the first two spots it can happen.
UnexpectedEOF was added for a very specific reason and I would prefer not to see it infect the entire standard library.
What is the use case here. How will knowing that the image is corrupt because it contained less than the necessary bytes of data, vs some other kind of complete but still corrupt state be useful to the caller ?
The following program prints EOF, which looks weird (whole image decoded?). Jpeg and png print UnexpectedEOF in this case. Gif should also return UnexpectedEOF.
go version devel +3cab476 Sun Jun 21 03:11:01 2015 +0000 linux/amd64
The text was updated successfully, but these errors were encountered: