Tautological postconditions: some merged contracts hold for any implementation (demonstrated by mutation) #630

Activity

1. KyleClouthier commented on Aug 6, 2026

   

   KyleClouthier

   on Aug 6, 2026

   Author

   More actions

   Follow-up: for_value_raw is not an outlier. I swept the corpus for the general shape and the pattern is systemic, so this is probably worth handling as a convention question and not as a one-line fix.

   The mechanical test

   A postcondition that references no input cannot constrain the input-output relation. It can only assert a property of the return value in isolation.

   That is checkable. Counting bare identifiers in each #[ensures] (excluding method names and paths, treating self and parameters as inputs) turns up 26 postconditions that mention no input at all.

   Two caveats before the list, because the heuristic is crude:

   • It misses type parameters. Layout::new's result.size() == mem::size_of::<T>() references T and is a perfectly good contract; my pattern only matched lowercase identifiers, so it flagged it. Those are false positives.
   • Input-free does not automatically mean vacuous. pad_to_align's result.size() % result.align() == 0 is not guaranteed by Layout, so it has teeth. It just cannot relate output to input.

   The subset that has no teeth at all

   The interesting cases are input-free and guaranteed by the return type. Those hold for every possible implementation. They cluster in four type families:

   type	postcondition	why it cannot fail
   NonZero	result.get() != 0	the type's invariant is non-zero
   NonNull	!result.pointer.is_null()	the type's invariant is non-null
   Unique	!result.is_null()	same
   Alignment	result.as_usize().is_power_of_two()	an enum of powers of two
   Layout	result.align().is_power_of_two()	enforced in from_size_align

   Instances I found, all currently merged:

   layout.rs:233     for_value_raw     align().is_power_of_two()          (mutation-proven above)
   layout.rs:273     align_to          ...align().is_power_of_two()       (has a meaningful sibling clause)
   alignment.rs:59   of                as_usize().is_power_of_two()
   alignment.rs:95   new_unchecked     as_usize().is_power_of_two()
   alignment.rs:111  as_usize          result.is_power_of_two()
   alignment.rs:120  as_nonzero        result.get().is_power_of_two()
   non_null.rs:138   dangling          !result.pointer.is_null() && ...
   non_null.rs:321   from_raw_parts    !result.pointer.is_null()
   non_null.rs:397   map_addr          !result.as_ptr().is_null()
   unique.rs:120     as_ptr            !result.is_null()
   nonzero.rs:807    count_ones        result.get() > 0
   nonzero.rs:840    rotate_left       result.get() != 0
   nonzero.rs:873    rotate_right      result.get() != 0
   

   I have only mutation-tested for_value_raw. The rest are candidates on the same reasoning, not results, and several sit beside genuinely strong clauses (rotate_left also asserts a round-trip through rotate_right, which is real).

   A disclosure that I think is the actual point

   While writing the blog post I added contracts to swap_bytes and reverse_bits, and I put result.get() != 0 on both. Same tautology. I copied it from the count_ones and rotate_left pattern directly above, because it looked like the local convention.

   The contracts I added still have teeth, since I also asserted the involution and that population count is preserved, and those do fail against a mutant. But the non-zero clause is decoration and I did not notice until I ran this sweep an hour later.

   That seems worth saying plainly, because it is the strongest evidence that this is a convention problem and not a diligence problem. The pattern is contagious specifically because it reads as house style. A contributor looking at neighbouring code will copy it, and nothing in review or CI distinguishes it from a clause that carries weight.

   Suggestion

   Nothing urgent, and I am not proposing anyone rewrite thirteen contracts tonight. But if a guideline for new contracts would be useful, something like:

   A postcondition should relate the result to an input. A clause that only asserts a property the return type already guarantees is satisfied by every implementation, and reachability checking cannot detect it because nothing is unreachable.

   Happy to open a PR strengthening the Layout and Alignment ones with mutants as evidence per clause, if that is useful. Equally happy to leave it if the weaker clauses are deliberate for reasons I have not understood.
2. KyleClouthier commented on Aug 6, 2026

   

   KyleClouthier

   on Aug 6, 2026

   Author

   More actions

   I said in the comment above that only for_value_raw was mutation-tested and the rest were candidates. I have now tested more of them. Four for four survive, across four files and four type families.

   Each mutant is written so the function does not do its job at all, while still type-checking and satisfying the return type's invariant. The harnesses are the merged ones, unmodified.

   function	mutant	merged harness	result
   Layout::for_value_raw	ignores its argument, returns Layout{size:1, align:1}	check_for_value_raw_i32	survives
   Layout::dangling	ignores self.align, always address 1	check_dangling	survives
   NonZero::count_ones	ignores self, always returns 1	nonzero_check_count_ones_for_{u8,i32}	survives
   NonNull::map_addr	never applies f, returns self	non_null_check_map_addr	survives

   Every one reports 0 failures.

   Two of these are worth spelling out because the weak clause is about the right property and still cannot see the bug.

   Layout::dangling is documented as returning a pointer "well-aligned for this Layout". Its contract is result.is_aligned(). But the return type is NonNull<u8> and align_of::<u8>() is 1, so the check asks whether an address is a multiple of one. A dangling that ignores self.align entirely and returns address 1 is misaligned for any layout requiring more, and passes.

   NonNull::map_addr exists to apply a function to a pointer's address. Its contract asks only whether the result is non-null, and NonNull cannot be null. A map_addr that never applies f satisfies its specification completely.

   Correction to my previous comment

   I listed the two CStr contracts (from_ptr and from_bytes_with_nul_unchecked, both result.is_safe()) among the candidates. That was wrong and I withdraw it. is_safe() expands to

   !bytes.is_empty() && bytes[len - 1] == 0 && !bytes[..len - 1].contains(&0)

   which is genuine content about the value, not something the type guarantees for free. A mutant returning a CStr with an interior nul would be caught. Those contracts have teeth and I should have checked before listing them.

   That takes the candidate set from 11 to 9.

   Where the nine stand

   4  mutation-tested, all survive     for_value_raw, Layout::dangling, count_ones, map_addr
   3  untested, same shape             NonNull::dangling, NonNull::from_raw_parts, Unique::as_ptr
   2  not testable as-is               Alignment::of (harness disabled behind kani#3905)
                                       Alignment::as_usize (no harness)
   

   I am reporting exactly what I ran. The three untested ones assert !is_null() on a NonNull or Unique return, so I expect the same outcome, but expecting is not measuring and I have not measured them.

   What I think this means

   Not that anyone was careless. The pattern is local convention, and I demonstrated how contagious it is by walking into it myself last night in the same file. count_ones is the sharpest illustration: the harness that discharges it is one I wrote yesterday. I set out to fill in seven contracts in nonzero.rs that had never been proved, and at least one of those proofs establishes nothing, because the contract establishes nothing. I would have shipped a green check with no content and felt good about it.

   The general rule that would have stopped all of this, me included:

   A postcondition should relate the result to an input. A clause asserting only what the return type already guarantees is satisfied by every implementation, and no reachability analysis can detect that, because nothing is unreachable.

   Still happy to open a PR strengthening these with a mutant per clause as evidence, if that is wanted. Reproduced with Kani 0.67.0 / CBMC 6.8.0 at 2138bc6; every file restored afterwards.