Skip to content

Commit 1fabcfa

Browse files
committed
fixups for some doc comments
1 parent 5bed8c4 commit 1fabcfa

File tree

2 files changed

+9
-8
lines changed

2 files changed

+9
-8
lines changed

libz-rs-sys/src/gz.rs

Lines changed: 6 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -14,9 +14,11 @@ use zlib_rs::deflate::Strategy;
1414
use zlib_rs::MAX_WBITS;
1515

1616
/// In the zlib C API, this structure exposes just enough of the internal state
17-
/// of an open gzFile to support the gzgetc() C macro. Since Rust code won't be
18-
/// using that C macro, we define gzFile_s as an empty structure. The first fields
19-
/// in GzState match what would be in the C version of gzFile_s.
17+
/// of an open [`gzFile`] to support the `gzgetc` C macro. Since Rust code won't be
18+
/// using that C macro, we define [`gzFile_s`] as an empty structure.
19+
// For ABI compatibility with zlib and zlib-ng, the first fields in [`GzState`] match
20+
// what would be in the C version of [`gzFile_s`]. But we don't want new users to rely
21+
// on this internal implementation, so the Rust [`gzFile_s`] is intentionally opaque.
2022
#[allow(non_camel_case_types)]
2123
pub enum gzFile_s {}
2224

@@ -2156,7 +2158,7 @@ pub unsafe extern "C" fn gzputs(file: gzFile, s: *const c_char) -> c_int {
21562158

21572159
/// Read one decompressed byte from `file`.
21582160
///
2159-
/// Note: The C header file zlib.h provides a macro wrapper for gzgetc that implements
2161+
/// Note: The C header file `zlib.h` provides a macro wrapper for `gzgetc` that implements
21602162
/// the fast path inline and calls this function for the slow path.
21612163
///
21622164
/// # Returns

zlib-rs/src/inflate/writer.rs

Lines changed: 3 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -352,10 +352,9 @@ impl<'a> Writer<'a> {
352352
}
353353

354354
// SAFETY: The caller ensured that src + length is within (or just at the end of)
355-
// a readable range of bytes.
356-
// FIXME: The other safety precondition for `add` is that the amount being added
357-
// must fit in an `isize`. Should that be part of the documented safety preconditions
358-
// for this function, so that our caller is responsible for ensuring it?
355+
// a readable range of bytes. LLVM disallows allocations bigger than isize::MAX,
356+
// so if src..src+length is a valid allocation (a precondition of this function)
357+
// the length will never exceed isize::MAX.
359358
let end = unsafe { src.add(length) };
360359

361360
// SAFETY: We checked above that length != 0, so there is at least one chunk remaining.

0 commit comments

Comments
 (0)