TODO: PR #1880 - inner icCmmStatBadSpaceLink is discarded and re-surfaced in icCmmStatIncorrectApply

[xsscx]

Post Merge Report

2026-08-15 11:41:22 UTC

References

#1748

Item 1

So an inner icCmmStatBadSpaceLink is discarded and re-surfaced by the outer Begin() as
icCmmStatIncorrectApply. The reporter's reasoning is sound. That swallow is worth fixing
independently of this bug — "Incorrect Apply object" tells a caller nothing about a nested
space-link failure, and it is why the report had to be reconstructed from source rather than
read off the error.

[github-actions]

Thanks for opening this issue.

The triage bot added initial labels based on the template and issue text. Maintainers may adjust labels as they review scope, reproduction details, CTest/regression needs, and security impact.

If you have questions, contact a listed Maintainer.

[colourbill-ctrl]

Mechanism, and the swallow is ten sites rather than one

Traced against master 49d0df51. The path the #1748 reporter hit -- RGB -> CMYK, perceptual,
BPC on -- with the frame that loses the status marked:

CIccXform::Begin()                      IccCmm.cpp:1716   if (!CalcFactors(...)) return icCmmStatIncorrectApply;
  CIccApplyBPC::CalcFactors()           IccApplyBPC.cpp:244   if (!calcBlackPoint(...)) return false;
    CIccApplyBPC::calcBlackPoint()      IccApplyBPC.cpp:283   !IsInput() -> calcDstBlackPoint
      CIccApplyBPC::calcDstBlackPoint() IccApplyBPC.cpp:399   pCmm = getBlackXfm(...); if (!pCmm) return false;
        CIccApplyBPC::getBlackXfm()     IccApplyBPC.cpp:633   if (pCmm->Begin()!=icCmmStatOk) { delete pCmm; return NULL; }  <-- status dies here

getBlackXfm returns CIccCmm*, so the inner icCmmStatBadSpaceLink has nowhere to go.
Every frame above it is bool, and IccCmm.cpp:1716 turns that false into
icCmmStatIncorrectApply -- which is why the report had to be reconstructed from source
rather than read off the error.

Reachability for that repro: the CMYK profile is the destination, so calcBlackPoint takes
the !IsInput() branch, and calcDstBlackPoint runs getBlackXfm whenever the profile has
BToA0 and is Gray/RGB/CMYK.

This issue names one discard; the file has ten

Grepping the family rather than the line:

function	discarded	lines
getBlackXfm	AddXform x2, Begin	612, 626, 633
pixelXfm	AddXform, Begin, Apply	571, 577, 582
calcDstBlackPoint	Apply x4	412, 424, 460, 505

All ten collapse to false and surface as the same icCmmStatIncorrectApply. A caller cannot
tell a bad space link from a failed black-point round trip from an allocation failure.

What the fix has to cross

One signature: IIccAdjustPCSXform::CalcFactors() (IccCmm.h:334) is a public, pure-virtual,
exported method returning bool, and it is the only frame between the discards and the
caller. CIccApplyBPC is its only implementor in tree, but IccCmm.h and IccApplyBPC.h are
both installed headers, so an out-of-tree implementor is possible and the interface shape is a
maintainer decision rather than mine.

Posting the trace so the mechanism is on the record. Happy to take the fix once the shape of
that interface change is settled -- and I would do all ten sites, not just the one this issue
names.

[colourbill-ctrl]

#2176 says an inner status is discarded and re-surfaced as
icCmmStatIncorrectApply, so a caller learns nothing about the nested failure.

The correction belongs at IccCmm.cpp:1717, not in IccApplyBPC.cpp: that line
reports "Incorrect Apply object" for a failed black-point estimation, which is
false on all 26 paths that reach it — the caller's apply object is fine in every
one. A code that is true of a failed black-point estimate fixes all 26 at once,
changes no interface and migrates no tests.

Two counts behind that, at 98129b81: code 8 has 34 return sites in
IccCmm.cpp and 33 concern the apply object or apply interface, so :1717 is
the lone outlier; and only 10 of the 26 returns discard a real
icStatusCMM, the other 16 never having had one (MaxL <= MinL is not a
status). Widening CalcFactors() therefore reaches 10 of 26 — I previously
called this blocked on an interface ruling, which was my error.

Question: a new appended icCmmStatBlackPointEstimation (precedent:
icCmmStatUnsupportedProfileClass = 19, #1843 04f636bf), or reuse of
icCmmStatUnsupported (18)? I lean to the first and will PR it with a CTest —
enum, GetStatusText(), Python mirror, no interface.

I have a read-only probe in which two unrelated failures collapse to code 8
against a passing control; it goes in the PR body.

Separately: the Python enum mirror stopped at 18, so #1843's value reads back as
code(19). Will file if useful.

[xsscx]

Separately: the Python enum mirror stopped at 18, so #1843 value reads back as code(19). Will file if useful.

@colourbill-ctrl Yes, Thank You

[colourbill-ctrl]

icCmmStatCantAdjustPcs = 20, "Cannot calculate PCS adjustment" — PR #2491.

Named for the IIccAdjustPCSXform interface rather than for black point. CalcFactors()
returns bool, so :1717 can emit exactly one code and its text has to be true of all 26
paths — and two of them estimate nothing at all (icAbsoluteColorimetric; the
link/abstract/namedColor classes). A black-point name would be false on those the same way
the current one is false on all of them. IIccAdjustPCSXform and
CIccCreateAdjustPCSXformHint are both ICCPROFLIB_API with installed headers, so an
out-of-tree implementer need not be doing BPC either.

Measured both ways, plus the 26/10/34/33 counts and the red/green: in the PR.
ctest -R iccdev.pcs-adjust-status.

Scope is the mislabelling only. The 10 sites that discard a real icStatusCMM still do —
that is the CalcFactors() interface ruling this issue is down to, and it is still yours.