#717 GTK3V2MAIN cgroup.c GroupOk(): write-failure return code silently discarded

[Allen D Byrne]

From .claude/cppcheck-deep-const-unused-shadow-plan.md (unreadVariable sampling). app/bin/cgroup.c:1121-1799, GroupOk() (static void, line 1113): BOOL_T rc = TRUE; is accumulated via rc &= fprintf(...)>0 / rc &= WriteCompoundPathsEndPtsSegs(...) etc. at several points (e.g. lines 1727, 1729, 1797, 1799) but never read, returned, or surfaced to the user. If writing the custom-parts file (xtrkcad.cus) fails partway (disk full, permissions), the user gets zero feedback and may believe their grouped turnout/structure was saved when it wasn't. Same silent-failure shape as several SF #675-#682 fixes. Needs a design decision before fixing (not purely mechanical): return BOOL_T instead of void and have the caller show ErrorMessage/NoticeMessage? Or bRunTests-style lprintf for headless runs, matching UndoFail's pattern in cundo.c? A regression fixture forcing a write failure (e.g. read-only target path) would validate a fix but doesn't exist today. Filing for another dev / a future session with an explicit UX decision rather than guessing. GTK3V2MAIN only.

[Martin Fischer]

Investigated. GroupOk() accumulates the write result into rc (rc &= fprintf(...)>0, rc &= WriteCompoundPathsEndPtsSegs(...)/WriteSegs(...)) but never reads rc afterward,
and OpenCustom("a")'s NULL return is only used to skip the write block — there's no error path at all.

GroupOk's signature can't productively change to return BOOL_T: it's registered via FormCreateDialog(&groupPG, ..., GroupOk, ...) against a shared void ()(void)
dialog-callback typedef used throughout the dialog system, so a signature change wouldn't propagate anywhere meaningful.

For reference, cundo.c's UndoFail (the pattern cited in the ticket) isn't just a log line — on its own file-open failure it calls NoticeMessage(MSG_OPEN_FAIL, ("Ok"),
NULL, ("Undo Trace"), path, strerror(errno)), a real modal dialog; it only falls back to lprintf in headless regression mode (bRunTests). Per this project's documented
error categories, a disk-full/permissions failure on a user-initiated save is a user-facing failure, not a fire-and-exit system error, so it should follow the same
pattern.

Fix: keep GroupOk void; after the write block, check for f == NULL or rc == FALSE and call NoticeMessage() with a new MSG_WRITE_FAIL entry mirroring MSG_OPEN_FAIL's
wording ("Cannot write %s file:\n%s:%s"), passing the .cus path and strerror(errno).

[Martin Fischer]

GroupOk() accumulated fprintf/WriteCompoundPathsEndPtsSegs/WriteSegs
return codes into rc but never checked it, so a failed write to
xtrkcad.cus (e.g. disk full) went completely silent. OpenCustom()
already reports its own fopen failures via MSG_OPEN_FAIL, but a
write failure after a successful open had no user-visible feedback.

Reuse the existing MSG_WRITE_FAILURE message (same one fileio.c and
dcustmgm.c already use for this exact situation) instead of adding a
new message id.