Cc @xavierleroy.

Concerning the Changes file : I was tempted to add this PR to the Change entry corresponding to #9698, but there does not seem to be one.

What do you think is the best to do?

As @damiendoligez mentioned in #9698, we will need to also adapt the ancient library.

An alternative solution would be to special-case the infix header in all the places of the runtime where we rely on the fact that out-of-heap headers are black. @xavierleroy: apart from the code in weak.c and the compactor (where we already plan to add this special case), do you see other places?

It's up to @damiendoligez to decide whether the compactor can tolerate white infix headers in out-of-heap closures.

Personally I'm reminded of Postel's robustness principle: it is more consistent and less surprising to color infix headers like we color closure headers: black for statically-allocated closures, white for dynamically-allocated closures.

@xavierleroy: apart from the code in weak.c and the compactor (where we already plan to add this special case), do you see other places?

Not off the top of my head. Generic primitives (comparison, etc) do not check colors.

I must have missed something in #9698. Where is the color of an infix header inspected? That seems like it is always a bug.

In weak.h, we have currently:

  ephemeron_again:
    if (child != caml_ephe_none
        && Is_block (child) && Is_in_value_area (child)){
      /* ... */
      if (Is_white_val (child) && !Is_young (child)){
      /* ... */
      }
    }

Where child can be any OCaml value (possibly an infix pointer).

And indeed, you are right, this is a bug.

That looks very much like it is a bug, probably a variant of #7810.

The Is_white_val(child) && !Is_young(child) looks like it's trying to detect whether child is an unmarked major heap block, but will incorrectly return true on an infix part of a marked major heap blcok (since infix headers are not mutated when the block changes color)

Ok, let me try to propose a fix for this.

will incorrectly return true on an infix part of a marked major heap blcok (since infix headers are not mutated when the block changes color

Well spotted!

Coming back to the present PR: what is the conclusion concerning infix headers in statically-allocated closures? Black or white?

Coming back to the present PR: what is the conclusion concerning infix headers in statically-allocated closures? Black or white?

My position is that infix headers do not in fact have a color, much like blocks on the minor heap. For consistency, the GC color bits should have a consistent value, and all-bits-zero is the obvious choice, matching what the native compiler and bytecode interpreter currently do. (I think that all translates to a vote for "white", since Caml_white == 0)

As @stedolan explained, it is always a bug to read the color of infix pointers, in the runtime and elsewhere. So this PR is pointless. Closing.

The issue concerning infix pointer in ephemerons has a tentative fix in #9742.