mirror of
https://github.com/jmcnamara/libxlsxwriter.git
synced 2026-05-15 14:15:54 -06:00
[GH-ISSUE #441] test/functional/test_image.py::TestCompareXLSXFiles::test_image58 failure on 32bit architectures #344
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#344
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 @AdrianBunk on GitHub (May 6, 2024).
Original GitHub issue: https://github.com/jmcnamara/libxlsxwriter/issues/441
https://buildd.debian.org/status/fetch.php?pkg=libxlsxwriter&arch=armhf&ver=1.1.7-1%7Eexp1&stamp=1714910384&raw=0
The problem is the following code commit
31b3314added in src/xmlwriter.c:valueis now a 64bit variable, but it is printed aslongwhich is 32bit.@hosiet FYI
@jmcnamara commented on GitHub (May 6, 2024):
Thanks for the report. I'll look into it.
@hosiet commented on GitHub (May 7, 2024):
I see changes in
42700eaf68, which has failed CI tests.If the variable to be printed has fixed length (e.g.,
in64_t), the printf format string should use functionalities in<inttype.h>with thePRId64macro. See https://stackoverflow.com/questions/9225567/how-to-portably-print-a-int64-t-type-in-c for more explanation. Using%ldor%lldare not portable across different platforms, and will cause build failure on one platform or another. Of course, we need to pay attention to whetherlxw_snprintf()is compatible with such format strings, though.In the meanwhile, the dirty hack of
Ignore %lld warning with gcc in xmlwriter.c.insrc/Makefileshall be removed.@jmcnamara commented on GitHub (May 7, 2024):
That was just a WIP attempt before I went to bed. :-)
I don't think any of those suggestions work with ANSI-C (whether I should still try to support that is a separate question).
Anyway, I went with a fix based on a double conversion/format. That will work in the integer range required for those large uint64_t offsets. The test case that was failing is more or less the maximum value for that attribute.
I tested it on a 32bit ubuntu system. Could you try it when you get a chance.
@hosiet commented on GitHub (May 7, 2024):
Thanks, I will try it and the rebuild result for all architectures will be available in 24 hours.
@jmcnamara commented on GitHub (May 7, 2024):
Ok. Let me know if you need it in a new release.
@jmcnamara commented on GitHub (May 8, 2024):
I have added a 32bit github action to hopefully catch issues like this in future.
@hosiet commented on GitHub (May 8, 2024):
Thanks, the new patch seems to have fixed the bug.
I don't mind having a new release; if you feel like postponing the release, I can always backport the patch only.
@jmcnamara commented on GitHub (May 24, 2024):
I'm still accumulating fixes for a new release so it is probably best to work with the patch/fix for now. I'll let you know when there is an update.
@jmcnamara commented on GitHub (Jul 31, 2024):
This fix is now available upstream in libxlsxwriter v1.1.8.
Note this version is tagged as
v1.1.8instead ofRELEASE_1.1.8for better interoperability with Xcode.@hosiet commented on GitHub (Jul 31, 2024):
Thanks for the info!