mirror of
https://github.com/jmcnamara/libxlsxwriter.git
synced 2026-05-15 14:15:54 -06:00
[GH-ISSUE #227] ZIP errors are not specified #183
Labels
No labels
awaiting user feedback
bug
cmake
cmake
docs
feature request
in progress
long term
medium term
medium term
pull-request
question
question
ready to close
short term
under investigation
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/libxlsxwriter#183
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @evanmiller on GitHub (May 14, 2019).
Original GitHub issue: https://github.com/jmcnamara/libxlsxwriter/issues/227
Originally assigned to: @jmcnamara on GitHub.
I am getting an error when creating a large XLSX file (2,000+ columns, 100,000+ rows).
The logic of
RETURN_ON_ZIP_ERRORindicates that the error is notZIP_ERRNO(néeZ_ERRNO) - however, I do not know what the actual error code is. Any way to bubble this up so I can access it from client code?@jmcnamara commented on GitHub (May 15, 2019):
Not without remapping all the zlib error codes. There are only 6 so that is probably doable. However, the zlib error codes aren't hugely informative either so they probably wouldn't be very useful to you anyway. See: https://www.zlib.net/manual.html
@evanmiller commented on GitHub (May 15, 2019):
Distinct from the Zlib errors there are the ZIP errors, which would help me narrow down the offending code path.
b616fb59ff/include/xlsxwriter/third_party/zip.h (L88-L90)@evanmiller commented on GitHub (May 15, 2019):
I should also add: The library's error messages incorrectly report all ZIP errors as Zlib errors.
@jmcnamara commented on GitHub (May 15, 2019):
Ah yes. Thanks.
@jmcnamara commented on GitHub (Jun 8, 2019):
I've pushed a fix for this to master where the library tries to bubble up the zip (not zlib) errors.
I simulated some of the failure conditions and the warning/error is now:
Can you try it out with your real world test case.
@evanmiller commented on GitHub (Jun 8, 2019):
Works perfectly. Thank you.