Possible Serious bug in gunzip.m
in [Matlab]
|
From: Yair Altman on 4 May 2010 17:57 "matlaberboy " <matlaberboy(a)gmail.NOSPAM.com> wrote in message <hrq1jo$j2d$1(a)fred.mathworks.com>... > [snip] it would not be beyond the realm of reason for a paragraph to be added to the Matlab supporting gunzip documentation stating that there is this known issue with the underlying java code. Now, **this** is an entirely reasonable request. Unfortunately, this was not what you requested from MathWorks support: You requested something to which they could not reasonably agree (to drop the function or fix the underlying implementation). I am pretty confident that if you approach MathWorks support again (remember to include the THREAD ID in the email) you will get a much more receptive answer to a request to update the documentation. Yair Altman http://UndocumentedMatlab.com
From: Walter Roberson on 5 May 2010 04:29
matlaberboy wrote: > This is very simple. > > This bug has been apparently known about in java for 8 years now. Not a bug. The requirements in this case are not documented in RFC 1952, so this is Undefined Behavior. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4691425 > If the decompression is going to fail, it would be nice if JAVA threw an > exception, rather than giving the false impression that all data has > been extracted. When you have a stream class, the end of stream logical marker means you have reached the end of the defined stream and should not read any further, rather than trying for another byte and seeing what happens. > However given we are in the real-world, it would not be > beyond the realm of reason for a paragraph to be added to the Matlab > supporting gunzip documentation stating that there is this known issue > with the underlying java code. I agree that there is no harm in documenting known limitations. The URL above gives a work-around Java class, but the license for the code is not made clear. |