FIXME regarding libpng-sys/libz-sys

[chirsz-ever]

How could this FIXME be explained?

tectonic/dpx/src/dpx_pdfobj.rs

Lines 2229 to 2238 in 957fad2

	let mut z: libz::z_stream = std::mem::zeroed();
	let mut wbuf: [libz::Bytef; 4096] = [0; 4096];
	// FIXME: Bug in libpng-sys
	// z.zalloc = null_mut();
	// z.zfree = null_mut();
	z.opaque = 0 as libz::voidpf;
	z.next_in = data as *mut libz::Bytef;
	z.avail_in = len as libz::uInt;
	z.next_out = wbuf.as_mut_ptr();
	z.avail_out = 4096i32 as libz::uInt;

[mulimoen]

libpng-sys does not take null-pointer allocation and free, when they should. If given null, they should use the system allocator. Seems no upstream issue was raised for this

[mulimoen]

FIXME is wrong in which library it is, it should be libz-sys. Issue was raised in rust-lang/libz-sys#55

[mulimoen]

libz-sys is rather ugly to fix with a patch, as it links to a system library and has several dependencies which must be patched at the same time.

See also
rust-lang/rust#8730

[crlf0710]

Yes, that would be a breaking change for that crate... Currently we are using std::mem::zeroed() as the workaround so it's not an urgent issue. But the warning is indeed annoying though.

[crlf0710]

The current hack will soon become a panic after rust-lang/rust#66059 lands. Currently it's running a crater run.

[cormacrelf]

Generally the flate2 crate solves this by implementing zalloc/zfree using std::alloc, and i already switched to it in #176. I’ll have a proper go at splitting that into something that passes.