I7: Should TEXT_TY_Say() set say__p = 1?

While looking through template code recently, I noticed the following (with comment added):

! ==== ==== ==== ==== ==== ==== ==== ==== ==== ====
! Text.i6t: Capitalised printing
! ==== ==== ==== ==== ==== ==== ==== ==== ==== ====

[ TEXT_TY_Say_Capitalised txt mod rc;
	mod = BlkValueCreate(TEXT_TY);
	TEXT_TY_SubstitutedForm(mod, txt);
	if (TEXT_TY_CharacterLength(mod) > 0) {
		BlkValueWrite(mod, 0, CharToCase(BlkValueRead(mod, 0), 1));
		TEXT_TY_Say(mod);
		rc = true;
		say__p = 1;		! <-- signal to paragraph control code that text has been output
	}
	BlkValueFree(mod);
	return rc;
];

but the related routine TEXT_TY_Say() does not do anything to set say__p:

! ==== ==== ==== ==== ==== ==== ==== ==== ==== ====
! Text.i6t: Printing
! ==== ==== ==== ==== ==== ==== ==== ==== ==== ====

[ TEXT_TY_Say txt  ch i dsize;
	if (txt==0) rfalse;
	if (txt-->0 & BLK_BVBITMAP_LONGBLOCKMASK == 0) return PrintI6Text(txt-->1);
	dsize = BlkValueLBCapacity(txt);
	for (i=0: i<dsize: i++) {
		ch = BlkValueRead(txt, i);
		if (ch == 0) break;
		#ifdef TARGET_ZCODE;
		print (char) ch;
		#ifnot; ! TARGET_ZCODE
		@streamunichar ch;
		#endif;
	}
	if (i == 0) rfalse;
	rtrue;
];

I can’t think of any reason why the capitalized version would want to set it but the uncapitalized version would not. Would there be a downside that I’m not seeing to moving the setting of say__p to TEXT_TY_Say()? For example:

! ==== ==== ==== ==== ==== ==== ==== ==== ==== ====
! Text.i6t: Printing (MODIFIED)
! ==== ==== ==== ==== ==== ==== ==== ==== ==== ====

[ TEXT_TY_Say txt  ch i dsize;
	...
	if (i == 0) rfalse;
	say__p = 1;	! ADDED	! <-- signals if at least one character was printed
	rtrue;
];

This change would make the signal in TEXT_TY_Say_Capitalized() redundant, so it could be removed from that routine.

Nothing went immediately wrong when I tried out a modified version on some test scenarios.

2 Likes

That probably does no harm, but if you look at the I6 generated by:

To say (val - sayable value of kind K) (documented at ph_say):
    (- {-say:val:K} -).

you’ll see the compiler directly inserts a say__p = 1, and the sayable value case includes the value of kind text case.

That said, there are lots of to say <a value of kind K> routines more specific than that that don’t set say__p and I wonder whether there could be misbehavior lurking there somewhere.

(Also, I know I have code that invokes TEXT_TY_Say directly, so I should probably swap in a version thereof that does set say__p.)