[bug] winspool names an undefined value ERROR_SPL_NO_STARTDOC and omits the real code

[p0dalirius]

Summary

winspool declares ErrorSplNoStartdoc at 0x00000E15, a value [MS-ERREF] 2.2 does not define at all, and renders it as ERROR_SPL_NO_STARTDOC. The specification assigns that name to 0x00000BBB (3003), which the interface's subset omits and therefore reports as undecoded hex.

Location

• File(s): network/dcerpc/interfaces/12345678-1234-abcd-ef00-0123456789ab/1.0/interface.go
• Line(s) / function(s): ErrorSplNoStartdoc at L143; StatusString() renders it at L200

Category

functional

Severity

low

A value the specification never assigns is reported under a real error's name, and the code that name belongs to is reported as hex. No comparison uses the constant, so control flow is unaffected.

Reproduction / Evidence

Verified by code analysis against [MS-ERREF] 2.2, using the committed extract at windows/errors/errgen/ms-erref-2.2-win32.tsv:

• interface.go:143 reads ErrorSplNoStartdoc uint32 = 0x00000E15 // ERROR_SPL_NO_STARTDOC (3605), and StatusString returns "ERROR_SPL_NO_STARTDOC" for it at L200.
• The table defines ERROR_SPL_NO_STARTDOC at 0x00000BBB (3003), immediately before ERROR_SPL_NO_ADDJOB at 0x00000BBC. Those are the only two SPL names in the Win32 table.
• 0x00000E15 (3605) has no row in the table. The highest Win32 code the specification defines below it is 0x00000BCE, and the range 0x00000E00–0x00000E40 is empty, so the value is not a Win32 system error code at all.
• Both the value and its parenthetical comment say 3605, so the declaration is self-consistent and nothing in the file contradicts it. The constant is referenced only by StatusString; all 88 method stubs compare against success alone.

Expected Behavior

0x00000BBB reports ERROR_SPL_NO_STARTDOC, and 0x00000E15 — which the specification does not define — reports its hexadecimal value.

Actual Behavior

0x00000E15 reports ERROR_SPL_NO_STARTDOC, and 0x00000BBB falls through to the hex default.

Root Cause

The subset was transcribed name-first, and this entry was paired with a value the specification does not assign. Nothing checked the pairing, because the constant and the string it renders to were written in the same edit and agree with each other.

Notes

Found while migrating winspool onto windows/errors/win32 for #1219, by deriving each constant's replacement from its value rather than its name. The same rule found the same class of defect in winreg (#1231).

This is the second instance, which makes it a pattern rather than an isolated slip: a hand-written per-interface subset can pair a correct name with an incorrect value and nothing in the interface will disagree. A generated table cannot express the error.

[p0dalirius]

Current state after the win32 migration (PR #1248)

The migration does not resolve this, deliberately. What it changes:

• The real 0x00000BBB now resolves through the shared table and reports ERROR_SPL_NO_STARTDOC, where the interface's subset previously omitted it and rendered it as hex. That half is fixed.
• 0x00000E15 keeps its local declaration in interface.go, with a comment recording that [MS-ERREF] 2.2 has no row for it, and StatusString survives reduced to that single case before deferring to win32.WIN32_ERROR(status).String().

It was not folded onto 0x00000BBB and it was not deleted, because the evidence only supports the narrow claim: [MS-ERREF] 2.2 defines no code at 0x00000E15. That is not the same as proving the value meaningless — it may come from a table outside 2.2. Deleting it would assert a conclusion the evidence does not reach, and silently changing its value would alter a declared constant on a guess.

What remains to decide, and needs someone with the print-protocol context:

1. Is 0x00000E15 a real code this interface can receive? If so it belongs in the local block, but under a name that is not ERROR_SPL_NO_STARTDOC — that name belongs to 0x00000BBB, and two values cannot share it.
2. If it is a transcription slip, the local declaration and the reduced StatusString both go, and win32.ERROR_SPL_NO_STARTDOC covers the real code with nothing left over.

Either way the name-to-value conflict is the part that is definitely wrong today.