[mvanhorn]

Summary

config.h and tar-gnu-embedded/stdint.h now follow SIZEOF_SIZE_T and SIZEOF_PTRDIFF_T. A 4-byte width selects 32-bit bit counts, an empty PTRDIFF_T_SUFFIX, a u SIZE_T_SUFFIX, and 32-bit SIZE_MAX and PTRDIFF_MIN/PTRDIFF_MAX; a wider width keeps the 64-bit macros. The armeabi-v7a and x86 bin.zip archives are rebuilt from that configuration. package() compiles build/tests/tar_integer_limits.c on the libgnu include path and stops when those limits disagree with the compiler types, and build/tests/tar_roundtrip.sh round-trips a small tree directly and through zstd and requires tar -tf to fail on a truncated archive.

On 32-bit Android, backup writes an archive and the follow-up tar listing check aborts with status 134, so the app deletes the file as broken. The icon archive fails in tar itself with memory exhausted. The same backup completes when the bundled tar is replaced with Termux's tar. The bundled gnulib headers fixed size_t and ptrdiff_t at 64-bit widths: BITSIZEOF_SIZE_T and BITSIZEOF_PTRDIFF_T were 64, the suffixes were ul and l, and SIZE_MAX, PTRDIFF_MIN, and PTRDIFF_MAX were 64-bit constants. 32-bit Android is ILP32, so those types are unsigned int and int; the constants overflow them and tar's allocation checks abort or report memory exhaustion.

Tests for this live in build/tests/tar_integer_limits.c and build/tests/tar_roundtrip.sh.

Fixes #443

[XayahSuSuSu]

Thanks for the pr:) Have you tried the build script in source-next/native/src/main/jni/external/tar/generate_tar_headers.sh? It should be fixed.

[mvanhorn]

@XayahSuSuSu I looked at generate_tar_headers.sh but couldn't run it here. It starts with sudo apt-get and downloads the NDK, so it needs an Ubuntu machine, and it stopped at the sudo prompt before generating anything.

Reading the script, its per-ABI output goes to source-next/.../embedded/, and the headers checked in there already handle 32-bit (_FILE_OFFSET_BITS 64 is defined only for armeabi-v7a and x86). This PR patches the shared headers under source/ that build_bin.sh uses for every ABI. Copying the script's 32-bit config.h there would define _FILE_OFFSET_BITS 64 for the 64-bit builds too, and its #undef BITSIZEOF_SIZE_T / BITSIZEOF_PTRDIFF_T would break build/tests/tar_integer_limits.c, which needs those macros.

So which do you prefer: move this to source-next (or close it, if source/ is going away and source-next already covers it), or keep the current header approach for source/?

[XayahSuSuSu]

@XayahSuSuSu I looked at generate_tar_headers.sh but couldn't run it here. It starts with sudo apt-get and downloads the NDK, so it needs an Ubuntu machine, and it stopped at the sudo prompt before generating anything.

Reading the script, its per-ABI output goes to source-next/.../embedded/, and the headers checked in there already handle 32-bit (_FILE_OFFSET_BITS 64 is defined only for armeabi-v7a and x86). This PR patches the shared headers under source/ that build_bin.sh uses for every ABI. Copying the script's 32-bit config.h there would define _FILE_OFFSET_BITS 64 for the 64-bit builds too, and its #undef BITSIZEOF_SIZE_T / BITSIZEOF_PTRDIFF_T would break build/tests/tar_integer_limits.c, which needs those macros.

So which do you prefer: move this to source-next (or close it, if source/ is going away and source-next already covers it), or keep the current header approach for source/?

The source folder will be removed once the new version is released, so I'd like to close this issue, thanks anyway:)