Closed AdrianBunk closed 3 months ago
Thanks for the report. I'll look into it.
I see changes in https://github.com/jmcnamara/libxlsxwriter/commit/42700eaf682fdab556e74c39625cb47947de3301 , 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 the PRId64
macro. See https://stackoverflow.com/questions/9225567/how-to-portably-print-a-int64-t-type-in-c for more explanation. Using %ld
or %lld
are not portable across different platforms, and will cause build failure on one platform or another. Of course, we need to pay attention to whether lxw_snprintf()
is compatible with such format strings, though.
In the meanwhile, the dirty hack of Ignore %lld warning with gcc in xmlwriter.c.
in src/Makefile
shall be removed.
I see changes in 42700ea , which has failed CI tests.
That was just a WIP attempt before I went to bed. :-)
See https://stackoverflow.com/questions/9225567/how-to-portably-print-a-int64-t-type-in-c for more explanation.
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.
Thanks, I will try it and the rebuild result for all architectures will be available in 24 hours.
Thanks, I will try it and the rebuild result for all architectures will be available in 24 hours.
Ok. Let me know if you need it in a new release.
I have added a 32bit github action to hopefully catch issues like this in future.
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.
I don't mind having a new release; if you feel like postponing the release, I can always backport the patch only.
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.
This fix is now available upstream in libxlsxwriter v1.1.8.
Note this version is tagged as v1.1.8
instead of RELEASE_1.1.8
for better interoperability with Xcode.
Thanks for the info!
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 31b3314 added in src/xmlwriter.c:
value
is now a 64bit variable, but it is printed aslong
which is 32bit.@hosiet FYI