List Archive


Thread Index


From: Dieter Baron <>
To: Andreas Falkenhahn <>
Subject: Re: Why should I return the size in ZIP_SOURCE_STAT?
Date: Fri, 3 Nov 2017 08:52:00 +0100


On 02.11.2017, at 21:10 , Andreas Falkenhahn <> wrote:

On 02.11.2017 at 12:13 Dieter Baron wrote:


On 01.11.2017, at 16:17 , Andreas Falkenhahn <> wrote:

On 01.11.2017 at 10:10 Dieter Baron wrote:

The only information you have to report accurately is
ZIP_STAT_SIZE and ZIP_STAT_CRC if your data is compressed or
encrypted). libzip can’t figure those out on its own.

Hmm, this is still confusing me. I'm not setting any of those
when adding a file from a source using zip_file_add(). My
code is just this:

     case ZIP_SOURCE_STAT: {
             struct zip_stat *st = (struct zip_stat *) data;         
             return sizeof(struct zip_stat);

And it's working fine so it looks like none of the ZIP_STAT_XXX
flags have to be set when adding files using zip_file_add()…

Yes, if you provide uncompressed, unencrypted data, all fields are optional.

What kind of source are you writing?

I'm writing a source that is used with zip_file_add(). The source
simply supplies data to be compressed to zip_file_add().

Do you know the size of the data beforehand? If so, why don’t you provide that information to libzip?

So it is
a "read source". According to the doc, a read source also needs
to implement ZIP_SOURCE_STAT so I just use the following dummy
code that doesn't set any fields:

       case ZIP_SOURCE_STAT: {
               struct zip_stat *st = (struct zip_stat *) data;         
               return sizeof(struct zip_stat);

This of course makes me wonder why it's necessary to implement
ZIP_SOURCE_STAT at all... it doesn't do anything, so I think
it should probably be made optional…

I want to encourage providing as much information as can be done easily. Making ZIP_SOURCE_STAT optional would encourage authors to omit providing information altogether.

If you really can’t provide any information beforehand, then your implementation is fine, and I don’t think it's too onerous.


Best regards,
Andreas Falkenhahn                  

Made by MHonArc.