Hi, On Thu, Nov 6, 2008 at 3:02 PM, Paolo Molaro <[EMAIL PROTECTED]> wrote:
> On 11/05/08 Alan McGovern wrote: > > 2) minizip exposes 'long' types in it's public API. At the moment I've > > wrapped these as IntPtr types. This will run on all platforms except > > Win64. To resolve this, we'd need to create a wrapper API which exposes > > the 'long' types as int64_t. > > When dealing with file offsets long is the wrong type to use, since > it's broken for 32 bit systems too, not only for win64. > int64_t should be used (or gint64...), but the code must be changed > to fix this issue, there is no point in adding a wrapper API, which > wouldn't solve the problem. > However this use case is likely to never be hit in System.IO.Packaging. The API requires that when you 'write' data to a zip archive, the data is also kept in memory. If you did try to use a 2gb file with this API, you'd end up trying to allocate a 2gb block of memory. But yes, this is should be fixed regardless of that because long types are unportable. What we need is to either submit a patch against zlib/minizip or just patch our local copy to change all 'long' types to int64_t. The other alternative is to use a different zip backend. Alan. > lupus > > -- > ----------------------------------------------------------------- > [EMAIL PROTECTED] debian/rules > [EMAIL PROTECTED] Monkeys do it better > _______________________________________________ > Mono-devel-list mailing list > [email protected] > http://lists.ximian.com/mailman/listinfo/mono-devel-list >
_______________________________________________ Mono-devel-list mailing list [email protected] http://lists.ximian.com/mailman/listinfo/mono-devel-list
