-
Simon Glass authored
The gzip API uses the u64 type in it, which is not available in the host build. This makes it impossible to include the header file. We could make this type available, but it seems unnecessary. Limiting the compression size to that of the 'unsigned long' type seems good enough. On 32-bit machines the limit then becomes 4GB, which likely exceeds available RAM anyway, therefore it should be sufficient. On 64-bit machines this is effectively u64 anyway. Update the header file and implementation to use 'ulong' instead of 'u64'. Add a definition of u32 for the cases that seem to need exactly that length. This should be safe enough. Signed-off-by:
Simon Glass <sjg@chromium.org>
Simon Glass authoredThe gzip API uses the u64 type in it, which is not available in the host build. This makes it impossible to include the header file. We could make this type available, but it seems unnecessary. Limiting the compression size to that of the 'unsigned long' type seems good enough. On 32-bit machines the limit then becomes 4GB, which likely exceeds available RAM anyway, therefore it should be sufficient. On 64-bit machines this is effectively u64 anyway. Update the header file and implementation to use 'ulong' instead of 'u64'. Add a definition of u32 for the cases that seem to need exactly that length. This should be safe enough. Signed-off-by:
Simon Glass <sjg@chromium.org>