Home > Archive > Compression > November 2004 > zlib/inflate error code -5
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
zlib/inflate error code -5
|
|
| Wolfgang Schwarz 2004-10-21, 3:55 am |
| Hallo,
calling the zlib function 'inflate' after 'inflateInit2' I get error code 5
(Z_BUF_ERROR)
In zlib.h I read:
.... Z_BUF_ERROR if no progress is possible or if there was not enough room
in that output buffer when Z_FINSH is used ...
But my output buffer has room enough ! (1000 time more than input buffer) !
What could be the reason for this error ?
Thank you for response
regards
Wolfgang Schwarz
34582 Borken/Germany
| |
| Eric D. Brown 2004-10-21, 3:55 pm |
| Wolfgang Schwarz wrote:
> Hallo,
>
> calling the zlib function 'inflate' after 'inflateInit2' I get error code 5
> (Z_BUF_ERROR)
>
> In zlib.h I read:
> ... Z_BUF_ERROR if no progress is possible or if there was not enough room
> in that output buffer when Z_FINSH is used ...
>
> But my output buffer has room enough ! (1000 time more than input buffer) !
> What could be the reason for this error ?
>
> Thank you for response
>
> regards
> Wolfgang Schwarz
> 34582 Borken/Germany
>
>
Before making the call, make sure that avail_in and avail_out are not
zero. When setting the parameter flush equal to Z_FINISH, also make sure
that avail_out is big enough to allow processing all pending input.
Note that a Z_BUF_ERROR is not fatal--another call to deflate() or
inflate() can be made with more input or output space. A Z_BUF_ERROR may
in fact be unavoidable depending on how the functions are used, since it
is not possible to tell whether or not there is more output pending when
strm.avail_out returns with zero.
| |
| Wolfgang Schwarz 2004-10-21, 3:55 pm |
|
"Eric D. Brown" <nospam@nowhere.com> schrieb im Newsbeitrag
news:10nfl87gghtolc0@corp.supernews.com...
> Wolfgang Schwarz wrote:
code 5[color=darkred]
room[color=darkred]
buffer) ![color=darkred]
> Before making the call, make sure that avail_in and avail_out are not
> zero. When setting the parameter flush equal to Z_FINISH, also make sure
> that avail_out is big enough to allow processing all pending input.
> Note that a Z_BUF_ERROR is not fatal--another call to deflate() or
> inflate() can be made with more input or output space. A Z_BUF_ERROR may
> in fact be unavoidable depending on how the functions are used, since it
> is not possible to tell whether or not there is more output pending when
> strm.avail_out returns with zero.
Eric,
avail_in/_out are not zero. They are loaded before calling 'inflateInit2'.
The .avail_out is 1000 times bigger than .avail_in - room enough ?
Any other idea looking on my code ?
'********************
'
' xsZLibStringInflate
'
'********************
Public Function xsZLibStringInflate(ByRef esvPacked As String) _
As String
Dim baPackedByte() As Byte
Dim tvStream As zStream
Dim ivPackedByteSize As Integer
Dim baUnpackedByte() As Byte
Dim ivUnpackedByte As Integer
Dim lvZLibResult As Long
' Abort if no Data
If Len(esvPacked) = 0 Then
Exit Function
End If
' Copy PackedData into Byte-Array
Call zVarCopy_String_To_ByteAry(esvPacked, baPackedByte)
'
ivPackedByteSize = UBound(baPackedByte)
ReDim baUnpackedByte(ivPackedByteSize * 1000)
ivUnpackedByte = UBound(baUnpackedByte)
With tvStream
.next_in = VarPtr(baPackedByte(0))
.avail_in = ivPackedByteSize + 1
.next_out = VarPtr(baUnpackedByte(0))
.avail_out = ivUnpackedByte
lvZLibResult = inflateInit2(tvStream, 15 + 16, ZLIB_VERSION,
Len(tvStream))
If lvZLibResult <> Z_OK Then
Stop
Call zZLibError("inflateInit2", lvZLibResult)
End If
lvZLibResult = inflate(tvStream, Z_FINISH)
If lvZLibResult <> Z_OK Then
Stop
Call zZLibError("inflate", lvZLibResult)
End If
lvZLibResult = inflateEnd(tvStream)
If lvZLibResult <> Z_OK Then
Stop
Call zZLibError("inflateEnd", lvZLibResult)
End If
Stop
' If .total_out Then
' Uncompress = vOut
' End If
End With
Stop 'DIMs
End Function
| |
| Eric D. Brown 2004-10-21, 3:55 pm |
| Wolfgang Schwarz wrote:
> "Eric D. Brown" <nospam@nowhere.com> schrieb im Newsbeitrag
> news:10nfl87gghtolc0@corp.supernews.com...
>
>
> code 5
>
>
> room
>
>
> buffer) !
>
>
>
> Eric,
>
> avail_in/_out are not zero. They are loaded before calling 'inflateInit2'.
> The .avail_out is 1000 times bigger than .avail_in - room enough ?
>
> Any other idea looking on my code ?
>
>
> '********************
> '
> ' xsZLibStringInflate
> '
> '********************
> Public Function xsZLibStringInflate(ByRef esvPacked As String) _
> As String
>
> Dim baPackedByte() As Byte
> Dim tvStream As zStream
> Dim ivPackedByteSize As Integer
> Dim baUnpackedByte() As Byte
> Dim ivUnpackedByte As Integer
> Dim lvZLibResult As Long
>
> ' Abort if no Data
> If Len(esvPacked) = 0 Then
> Exit Function
> End If
>
> ' Copy PackedData into Byte-Array
> Call zVarCopy_String_To_ByteAry(esvPacked, baPackedByte)
> '
> ivPackedByteSize = UBound(baPackedByte)
> ReDim baUnpackedByte(ivPackedByteSize * 1000)
> ivUnpackedByte = UBound(baUnpackedByte)
> With tvStream
> .next_in = VarPtr(baPackedByte(0))
> .avail_in = ivPackedByteSize + 1
> .next_out = VarPtr(baUnpackedByte(0))
> .avail_out = ivUnpackedByte
>
> lvZLibResult = inflateInit2(tvStream, 15 + 16, ZLIB_VERSION,
> Len(tvStream))
> If lvZLibResult <> Z_OK Then
> Stop
> Call zZLibError("inflateInit2", lvZLibResult)
> End If
>
> lvZLibResult = inflate(tvStream, Z_FINISH)
> If lvZLibResult <> Z_OK Then
> Stop
> Call zZLibError("inflate", lvZLibResult)
> End If
>
> lvZLibResult = inflateEnd(tvStream)
> If lvZLibResult <> Z_OK Then
> Stop
> Call zZLibError("inflateEnd", lvZLibResult)
> End If
>
> Stop
> ' If .total_out Then
> ' Uncompress = vOut
> ' End If
>
> End With
>
>
> Stop 'DIMs
> End Function
>
>
I currently can't thoroughly troubleshoot your code, since I'm working
(I'll look at it a bit more when I get home); however, I already see a
few issues that immediately jump out at me.
First off, you have both ivPackedByteSize and ivUnpackedByte dimmed as
an integer, where you should declare them as at least a Long. The
reason is because an integer is defined as an unsigned value of -32767
to 32767; therefore, if you're working with large files... you'll
encounter "overflow" errors.
Secondly, is an issue with the following lines:
.next_in = VarPtr(baPackedByte(0))
.avail_in = ivPackedByteSize + 1
.next_out = VarPtr(baUnpackedByte(0))
.avail_out = ivUnpackedByte
Your staticly referring to the baPackedByte() and baUnpackedByte() using
ONLY the first array value, which is 0.
Next, in practice, your baUnpackedByte array "buffer" doesn't need to be
1000 times larger (using too much memory). The reason is, if you were
to work with even a 1MB file, your baUnpackedByte buffer would require
1GB of RAM!!!
| |
| Wolfgang Schwarz 2004-10-21, 8:55 pm |
| Eric
> First off, you have both ivPackedByteSize and ivUnpackedByte dimmed as
> an integer, where you should declare them as at least a Long. The
> reason is because an integer is defined as an unsigned value of -32767
> to 32767; therefore, if you're working with large files... you'll
> encounter "overflow" errors.
>
I have changed from integer to long.
My aktually Strings have a len of 2000 Byte, but one day .... :-)
> Secondly, is an issue with the following lines:
> .next_in = VarPtr(baPackedByte(0))
> .avail_in = ivPackedByteSize + 1
> .next_out = VarPtr(baUnpackedByte(0))
> .avail_out = ivUnpackedByte
>
> Your staticly referring to the baPackedByte() and baUnpackedByte() using
> ONLY the first array value, which is 0.
>
When I changed to VarPtr(baPackedByte) (the whole array), I get a 'Type
Mismatch' during compilation. VarPtr(baPackedByte(0)) is the only way that
works !
> Next, in practice, your baUnpackedByte array "buffer" doesn't need to be
> 1000 times larger (using too much memory). The reason is, if you were
> to work with even a 1MB file, your baUnpackedByte buffer would require
> 1GB of RAM!!!
I only want to show you that the buffer is big enough.
I test with 2 times.
What is the best buffer size ?
regards
Wolfgang Schwarz
| |
| Attila 2004-10-29, 3:55 am |
| I have the same problem !
Any idea ?
In my case inflate() uncompress data correct but return -5
bye
"Wolfgang Schwarz" <schwarz.wolfgang@t-online.de> wrote in message news:<cl9ace$6i1$03$1@news.t-online.com>...
> Eric
>
>
> I have changed from integer to long.
> My aktually Strings have a len of 2000 Byte, but one day .... :-)
>
>
> When I changed to VarPtr(baPackedByte) (the whole array), I get a 'Type
> Mismatch' during compilation. VarPtr(baPackedByte(0)) is the only way that
> works !
>
>
> I only want to show you that the buffer is big enough.
> I test with 2 times.
> What is the best buffer size ?
>
> regards
> Wolfgang Schwarz
| |
| Matt Mahoney 2004-10-29, 3:55 pm |
|
"Attila" <sintel@katamail.com> wrote in message
news:c0c818ea.0410282239.3cbdf637@posting.google.com...
> I have the same problem !
> Any idea ?
> In my case inflate() uncompress data correct but return -5
This is defined as Z_BUF_ERROR in zlib.h. From the source comments:
inflate() returns Z_OK if some progress has been made (more input
processed
or more output produced), Z_STREAM_END if the end of the compressed data has
been reached and all uncompressed output has been produced, Z_NEED_DICT if a
preset dictionary is needed at this point, Z_DATA_ERROR if the input data
was
corrupted (input stream not conforming to the zlib format or incorrect check
value), Z_STREAM_ERROR if the stream structure was inconsistent (for example
if next_in or next_out was NULL), Z_MEM_ERROR if there was not enough
memory,
Z_BUF_ERROR if no progress is possible or if there was not enough room in
the
output buffer when Z_FINISH is used. Note that Z_BUF_ERROR is not fatal, and
inflate() can be called again with more input and more output space to
continue decompressing. If Z_DATA_ERROR is returned, the application may
then
call inflateSync() to look for a good compression block if a partial
recovery
of the data is desired.
-- Matt Mahoney
| |
| Mark Adler 2004-10-30, 3:55 am |
| "Matt Mahoney" <matmahoney@yahoo.com> wrote in message news:<6Ptgd.11570$5i5.2512@newsread2.news.atl.earthlink.net>...
> This is defined as Z_BUF_ERROR in zlib.h. From the source comments:
....
> Note that Z_BUF_ERROR is not fatal, and
> inflate() can be called again with more input and more output space to
> continue decompressing.
And to further emphasize, here is the entry from the FAQ:
5. deflate() or inflate() returns Z_BUF_ERROR.
Before making the call, make sure that avail_in and avail_out are not
zero. When setting the parameter flush equal to Z_FINISH, also make sure
that avail_out is big enough to allow processing all pending input.
Note that a Z_BUF_ERROR is not fatal--another call to deflate() or
inflate() can be made with more input or output space. A Z_BUF_ERROR
may in fact be unavoidable depending on how the functions are used, since
it is not possible to tell whether or not there is more output pending
when strm.avail_out returns with zero.
mark
| |
| Eric D. Brown 2004-10-30, 3:55 am |
| Mark Adler wrote:
> "Matt Mahoney" <matmahoney@yahoo.com> wrote in message news:<6Ptgd.11570$5i5.2512@newsread2.news.atl.earthlink.net>...
>
>
> ...
>
>
>
> And to further emphasize, here is the entry from the FAQ:
>
> 5. deflate() or inflate() returns Z_BUF_ERROR.
>
> Before making the call, make sure that avail_in and avail_out are not
> zero. When setting the parameter flush equal to Z_FINISH, also make sure
> that avail_out is big enough to allow processing all pending input.
> Note that a Z_BUF_ERROR is not fatal--another call to deflate() or
> inflate() can be made with more input or output space. A Z_BUF_ERROR
> may in fact be unavoidable depending on how the functions are used, since
> it is not possible to tell whether or not there is more output pending
> when strm.avail_out returns with zero.
>
> mark
Why do all these things have to be so damned complicated... having 15+
errors, that aren't actually errors... but maybe could be. This is
bullshit, in my opinion. Another reason why I don't personally use the
zlib library!
If I have to code error controls for the actual error controls
themselves, something is majorly wrong.
Respectfully,
Eric D. Brown
| |
| Mark Adler 2004-10-31, 3:55 am |
| "Eric D. Brown" <nospam@nowhere.com> wrote in message news:<10o67c98135hafe@corp.supernews.com>...
> Why do all these things have to be so damned complicated... having 15+
> errors, that aren't actually errors... but maybe could be. This is
> bullshit, in my opinion. Another reason why I don't personally use the
> zlib library!
>
> If I have to code error controls for the actual error controls
> themselves, something is majorly wrong.
Hmm. If you don't use zlib, then perhaps you shouldn't be making
stuff up.
I don't know what the "15+ errors" are, nor do I know under what
circumstances one would "code error controls for the actual error
controls".
The return value in question, Z_BUF_ERROR, can be and is ignored in
properly written code. (We should have called it a warning instead of
an error, but we're kind of stuck with the interface.) It is provided
as a convenience to the programmer during debugging to see that their
code is stuck in an infinite loop because no progress being made by
inflate() or deflate() over repeated calls due to no input provided or
no output space available. If you see Z_BUF_ERROR being returned
continuously, then that's what's happening. Once the code is debugged
and is properly feeding and flushing inflate() or deflate(), then
Z_BUF_ERROR can be treated the same as Z_OK.
For those who would find it useful, I have written an example,
provided below, that shows the proper use of inflate() and deflate(),
including complete handling of relevant return values.
As for your other unstated reasons for not using zlib, if any of those
are issues with zlib based on actual experience, we'd be happy to
consider remedies.
mark
/* zpipe.c: example of proper use of zlib's inflate() and deflate()
Not copyrighted -- provided to the public domain
Version 1.0 30 October 2004 Mark Adler */
#include <stdio.h>
#include <string.h>
#include "zlib.h"
#define CHUNK 16384
/* Compress from file source to file dest until EOF on source.
def() returns Z_OK on success, Z_MEM_ERROR if memory could not be
allocated for processing, Z_STREAM_ERROR if an invalid compression
level is supplied, Z_VERSION_ERROR if the version of zlib.h and the
version of the library linked do not match, or Z_ERRNO if there is
an error reading or writing the files. */
int def(FILE *source, FILE *dest, int level)
{
int ret, flush;
unsigned have;
z_stream strm;
char in[CHUNK];
char out[CHUNK];
/* allocate deflate state */
strm.zalloc = Z_NULL;
strm.zfree = Z_NULL;
strm.opaque = Z_NULL;
ret = deflateInit(&strm, level);
if (ret != Z_OK)
return ret;
/* compress until end of file */
do {
strm.avail_in = fread(in, 1, CHUNK, source);
if (ferror(source)) {
deflateEnd(&strm);
return Z_ERRNO;
}
flush = feof(source) ? Z_FINISH : Z_NO_FLUSH;
strm.next_in = in;
/* run deflate() on input until output buffer not full, finish
compression if all of source has been read in */
do {
strm.avail_out = CHUNK;
strm.next_out = out;
deflate(&strm, flush); /* no relevant return value */
have = CHUNK - strm.avail_out;
if (fwrite(out, 1, have, dest) != have || ferror(dest)) {
deflateEnd(&strm);
return Z_ERRNO;
}
} while (strm.avail_out == 0);
} while (flush != Z_FINISH);
/* clean up and return */
deflateEnd(&strm);
return Z_OK;
}
/* Decompress from file source to file dest until deflate stream ends
or EOF.
inf() returns Z_OK on success, Z_MEM_ERROR if memory could not be
allocated for processing, Z_DATA_ERROR if the deflate data is
invalid or incomplete, Z_VERSION_ERROR if the version of zlib.h and
the version of the library linked do not match, or Z_ERRNO if there
is an error reading or writing the files. */
int inf(FILE *source, FILE *dest)
{
int ret;
unsigned have;
z_stream strm;
char in[CHUNK];
char out[CHUNK];
/* allocate inflate state */
strm.zalloc = Z_NULL;
strm.zfree = Z_NULL;
strm.opaque = Z_NULL;
strm.avail_in = 0;
strm.next_in = Z_NULL;
ret = inflateInit(&strm);
if (ret != Z_OK)
return ret;
/* decompress until deflate stream ends or end of file */
do {
strm.avail_in = fread(in, 1, CHUNK, source);
if (ferror(source)) {
inflateEnd(&strm);
return Z_ERRNO;
}
if (strm.avail_in == 0)
break;
strm.next_in = in;
/* run inflate() on input until output buffer not full */
do {
strm.avail_out = CHUNK;
strm.next_out = out;
ret = inflate(&strm, Z_NO_FLUSH);
if (ret == Z_NEED_DICT)
ret = Z_DATA_ERROR;
if (ret == Z_MEM_ERROR || ret == Z_DATA_ERROR) {
inflateEnd(&strm);
return ret;
}
have = CHUNK - strm.avail_out;
if (fwrite(out, 1, have, dest) != have || ferror(dest)) {
inflateEnd(&strm);
return Z_ERRNO;
}
} while (strm.avail_out == 0);
} while (ret != Z_STREAM_END);
/* clean up and return */
inflateEnd(&strm);
return ret == Z_STREAM_END ? Z_OK : Z_DATA_ERROR;
}
/* report a zlib or i/o error */
void zerr(int ret)
{
fputs("zpipe: ", stderr);
switch (ret) {
case Z_ERRNO:
if (ferror(stdin))
fputs("error reading stdin\n", stderr);
if (ferror(stdout))
fputs("error writing stdout\n", stderr);
break;
case Z_STREAM_ERROR:
fputs("invalid compression level\n", stderr);
break;
case Z_DATA_ERROR:
fputs("invalid or incomplete deflate data\n", stderr);
break;
case Z_MEM_ERROR:
fputs("out of memory\n", stderr);
break;
case Z_VERSION_ERROR:
fputs("zlib version mismatch!\n", stderr);
}
}
/* compress or decompress from stdin to stdout */
int main(int argc, char **argv)
{
int ret;
/* do compression if no arguments */
if (argc == 1) {
ret = def(stdin, stdout, Z_DEFAULT_COMPRESSION);
if (ret != Z_OK)
zerr(ret);
return ret;
}
/* do decompression if -d specified */
else if (argc == 2 && strcmp(argv[1], "-d") == 0) {
ret = inf(stdin, stdout);
if (ret != Z_OK)
zerr(ret);
return ret;
}
/* otherwise, report usage */
else {
fputs("zpipe usage: zpipe [-d] < source > dest\n", stderr);
return 1;
}
}
| |
| Eric D. Brown 2004-11-01, 3:55 am |
| Mark Adler wrote:
> "Eric D. Brown" <nospam@nowhere.com> wrote in message news:<10o67c98135hafe@corp.supernews.com>...
>
>
>
> Hmm. If you don't use zlib, then perhaps you shouldn't be making
> stuff up.
>
> I don't know what the "15+ errors" are, nor do I know under what
> circumstances one would "code error controls for the actual error
> controls".
>
> The return value in question, Z_BUF_ERROR, can be and is ignored in
> properly written code. (We should have called it a warning instead of
> an error, but we're kind of stuck with the interface.) It is provided
> as a convenience to the programmer during debugging to see that their
> code is stuck in an infinite loop because no progress being made by
> inflate() or deflate() over repeated calls due to no input provided or
> no output space available. If you see Z_BUF_ERROR being returned
> continuously, then that's what's happening. Once the code is debugged
> and is properly feeding and flushing inflate() or deflate(), then
> Z_BUF_ERROR can be treated the same as Z_OK.
>
> For those who would find it useful, I have written an example,
> provided below, that shows the proper use of inflate() and deflate(),
> including complete handling of relevant return values.
>
> As for your other unstated reasons for not using zlib, if any of those
> are issues with zlib based on actual experience, we'd be happy to
> consider remedies.
>
> mark
>
>
> /* zpipe.c: example of proper use of zlib's inflate() and deflate()
> Not copyrighted -- provided to the public domain
> Version 1.0 30 October 2004 Mark Adler */
>
> #include <stdio.h>
> #include <string.h>
> #include "zlib.h"
>
> #define CHUNK 16384
>
> /* Compress from file source to file dest until EOF on source.
> def() returns Z_OK on success, Z_MEM_ERROR if memory could not be
> allocated for processing, Z_STREAM_ERROR if an invalid compression
> level is supplied, Z_VERSION_ERROR if the version of zlib.h and the
> version of the library linked do not match, or Z_ERRNO if there is
> an error reading or writing the files. */
> int def(FILE *source, FILE *dest, int level)
> {
> int ret, flush;
> unsigned have;
> z_stream strm;
> char in[CHUNK];
> char out[CHUNK];
>
> /* allocate deflate state */
> strm.zalloc = Z_NULL;
> strm.zfree = Z_NULL;
> strm.opaque = Z_NULL;
> ret = deflateInit(&strm, level);
> if (ret != Z_OK)
> return ret;
>
> /* compress until end of file */
> do {
> strm.avail_in = fread(in, 1, CHUNK, source);
> if (ferror(source)) {
> deflateEnd(&strm);
> return Z_ERRNO;
> }
> flush = feof(source) ? Z_FINISH : Z_NO_FLUSH;
> strm.next_in = in;
>
> /* run deflate() on input until output buffer not full, finish
> compression if all of source has been read in */
> do {
> strm.avail_out = CHUNK;
> strm.next_out = out;
> deflate(&strm, flush); /* no relevant return value */
> have = CHUNK - strm.avail_out;
> if (fwrite(out, 1, have, dest) != have || ferror(dest)) {
> deflateEnd(&strm);
> return Z_ERRNO;
> }
> } while (strm.avail_out == 0);
> } while (flush != Z_FINISH);
>
> /* clean up and return */
> deflateEnd(&strm);
> return Z_OK;
> }
>
>
> /* Decompress from file source to file dest until deflate stream ends
> or EOF.
> inf() returns Z_OK on success, Z_MEM_ERROR if memory could not be
> allocated for processing, Z_DATA_ERROR if the deflate data is
> invalid or incomplete, Z_VERSION_ERROR if the version of zlib.h and
> the version of the library linked do not match, or Z_ERRNO if there
> is an error reading or writing the files. */
> int inf(FILE *source, FILE *dest)
> {
> int ret;
> unsigned have;
> z_stream strm;
> char in[CHUNK];
> char out[CHUNK];
>
> /* allocate inflate state */
> strm.zalloc = Z_NULL;
> strm.zfree = Z_NULL;
> strm.opaque = Z_NULL;
> strm.avail_in = 0;
> strm.next_in = Z_NULL;
> ret = inflateInit(&strm);
> if (ret != Z_OK)
> return ret;
>
> /* decompress until deflate stream ends or end of file */
> do {
> strm.avail_in = fread(in, 1, CHUNK, source);
> if (ferror(source)) {
> inflateEnd(&strm);
> return Z_ERRNO;
> }
> if (strm.avail_in == 0)
> break;
> strm.next_in = in;
>
> /* run inflate() on input until output buffer not full */
> do {
> strm.avail_out = CHUNK;
> strm.next_out = out;
> ret = inflate(&strm, Z_NO_FLUSH);
> if (ret == Z_NEED_DICT)
> ret = Z_DATA_ERROR;
> if (ret == Z_MEM_ERROR || ret == Z_DATA_ERROR) {
> inflateEnd(&strm);
> return ret;
> }
> have = CHUNK - strm.avail_out;
> if (fwrite(out, 1, have, dest) != have || ferror(dest)) {
> inflateEnd(&strm);
> return Z_ERRNO;
> }
> } while (strm.avail_out == 0);
> } while (ret != Z_STREAM_END);
>
> /* clean up and return */
> inflateEnd(&strm);
> return ret == Z_STREAM_END ? Z_OK : Z_DATA_ERROR;
> }
>
> /* report a zlib or i/o error */
> void zerr(int ret)
> {
> fputs("zpipe: ", stderr);
> switch (ret) {
> case Z_ERRNO:
> if (ferror(stdin))
> fputs("error reading stdin\n", stderr);
> if (ferror(stdout))
> fputs("error writing stdout\n", stderr);
> break;
> case Z_STREAM_ERROR:
> fputs("invalid compression level\n", stderr);
> break;
> case Z_DATA_ERROR:
> fputs("invalid or incomplete deflate data\n", stderr);
> break;
> case Z_MEM_ERROR:
> fputs("out of memory\n", stderr);
> break;
> case Z_VERSION_ERROR:
> fputs("zlib version mismatch!\n", stderr);
> }
> }
>
> /* compress or decompress from stdin to stdout */
> int main(int argc, char **argv)
> {
> int ret;
>
> /* do compression if no arguments */
> if (argc == 1) {
> ret = def(stdin, stdout, Z_DEFAULT_COMPRESSION);
> if (ret != Z_OK)
> zerr(ret);
> return ret;
> }
>
> /* do decompression if -d specified */
> else if (argc == 2 && strcmp(argv[1], "-d") == 0) {
> ret = inf(stdin, stdout);
> if (ret != Z_OK)
> zerr(ret);
> return ret;
> }
>
> /* otherwise, report usage */
> else {
> fputs("zpipe usage: zpipe [-d] < source > dest\n", stderr);
> return 1;
> }
> }
On the "making stuff up"... perhaps you can point out where I'm "making
stuff up"? Now that I understand you "may be" a participating developer
of the zlib library, I completely understand your strong defense of your
product; however, I'll let these conversations speak for themselves
(obviously your error explanations are a bit too confusing and need
simplification). You even pointed out that perhaps it shouldn't have
been called an "error". However, there are a few "error code" responses
that could have either resulted in an "actual error" or something that
could have been ignored. That leaves us creating "error controls" for
the zlib library "error responses" (was it an actual stop error, or can
it be ignored?)
For the "other" personal reasons that I don't use zlib... it's because I
create my own controls and ActiveX components for my compression needs.
I no longer rely on ANY 3rd-party components for any of my development.
| |
| Mark Adler 2004-11-01, 8:55 pm |
| "Eric D. Brown" <nospam@nowhere.com> wrote in message news:<10obeb84pok6bba@corp.supernews.com>...
> On the "making stuff up"... perhaps you can point out where I'm "making
> stuff up"?
I thought I did that in my subsequent paragraph, copied here:
To be more explicit, there are no "15+ errors". There are five:
#define Z_STREAM_ERROR (-2)
#define Z_DATA_ERROR (-3)
#define Z_MEM_ERROR (-4)
#define Z_BUF_ERROR (-5)
#define Z_VERSION_ERROR (-6)
(There is also Z_ERRNO, -1, for the gz* routines in zlib that use
stdio, to pass along stdio errors.) Z_STREAM_ERROR, Z_BUF_ERROR, and
Z_VERSION_ERROR indicate zlib usage bugs or linkage errors, and are
not a usually a concern in a production application. However
Z_VERSION_ERROR should be checked for applications that use a shared
library. The only really relevant errors are Z_DATA_ERROR and
Z_MEM_ERROR.
Five is the number of errors that we felt would be of use to the
application. If there were 15+ useful errors to report, then that's
what we would have, and that would be a good thing. stdio routines
can report far more errors than that.
The other made-up item is the assertion that "error controls for
actual error controls" would be needed, which is not the case, since
there is no response at all required by the application for the error
being discussed, Z_BUF_ERROR.
[color=darkred]
> That leaves us creating "error controls" for
> the zlib library "error responses" (was it an actual stop error, or can
> it be ignored?)
The zlib FAQ answer, that you yourself properly provided in the first
response on this thread (thank you for that) states clearly that
Z_BUF_ERROR is not fatal, and that the application can call inflate()
or deflate() after that with more input data or output space.
> For the "other" personal reasons that I don't use zlib... it's because I
> create my own controls and ActiveX components for my compression needs.
> I no longer rely on ANY 3rd-party components for any of my development.
Fair enough. If you have the time and resources, it's far better to
be cognizant of all of the code in your application. We came close to
losing a rover on Mars earlier this year because we didn't fully
understand and characterize the behavior of some third-party
commercial software we used on the rover.
mark
| |
| Wolfgang Schwarz 2004-11-03, 8:55 am |
| Attila,
does your problems still occurs ?
Which language do you use ?
I can tell you something about VB6 and zlib.
For details inform me per PM too, I'am not here every day
regards
Wolfgang Schwarz
| |
|
| Mark et al.,
I am using tis library and sometimes get a Z_OK or a Z_BUF_ERROR. It appears that, as you note, the Z_BUF_ERROR (-5) is not a problem. However I am using the "uncompress" function. Upon success, this function will take the input data and return a buffer with the uncompressed data as well as a byte count for the uncompressed data. When a Z_OK is returned, the total byes are indeed returned. When a Z_BUF_ERROR occurs, the value returned from uncompress for total bytes is the sze of the buffer varibale itself. So, how would one go about determining how many uncompressed data were put into the destination buffer? |
|
|
|
|