Re: curses_trace() - version 6.6

"G. Branden Robinson" <[email protected]> Sat, 15 Aug 2026 11:52:09 -0500
Newsgroups	gmane.comp.lib.ncurses.bugs
Message-ID	<20260815165209.42b5tvm627t6u6wg@illithid>
At 2026-08-05T15:09:13-0400, Thomas Dickey wrote:
> On Wed, Aug 05, 2026 at 07:41:24PM +0200, Björn Försterling wrote:
> > And `curses_trace(TRACE_MAXIMUM)` seems to return 0 even when
> > tracing is available and writing to a file called "trace" works.
> > Probably because the previous bitmask was 0.
> 
> yes :-)
> 
> > But how do you check if tracing is available?
> 
> call the function twice:
> 
> 	curses_trace(TRACE_MAXIMUM);
> 	rc = trace(TRACE_NORMAL);
> 
> curs_set and umask do something like that with return-codes.

Ah, but you don't have to call curs_set twice.

kernel(3NCURSES)              Library calls             kernel(3NCURSES)
...
     int curs_set(int visibility);
...
   curs_set
     curs_set adjusts the cursor visibility to “invisible”, “visible”,
     “very visible”, as its argument is 0, 1, or 2, respectively.  It
     returns the previous visibility if the requested one is supported,
     and ERR otherwise.

curs_set returns a _signed_ integral value, with negative values
reserved as an error indication.

Since ncurses ABI 7 appears to be open for business,[1] I propose that
curses_trace() change its return type to a "regular" signed `int`; that
way this pattern of calling curses_trace() twice to decide whether the
feature is enabled becomes unnecessary.

If the tracing feature is disabled, curses_trace() can return ERR.

There are only 13 distinct event types.

$ sed -n 209,210p include/curses.tail
#define TRACE_SHIFT     13      /* number of bits in the trace masks */
#define TRACE_MAXIMUM   ((1 << TRACE_SHIFT) - 1) /* maximum trace level */

Even with a PDP-11 sized `int`, you could convert `result` to `int` and
have 2 bits to spare.  On a 32-bit machine I don't think you'll ever run
out of room, to say nothing of 64-bit hosts.

What do you think?

Regards,
Branden

[1] https://lists.gnu.org/archive/html/bug-ncurses/2025-05/msg00015.html

[2] It's not a "mask", but rather a bit vector; each set bit _enables_ a
    feature rather than disabling it or "masking it off".  Early Unix
    hackers were apparently so fascinated by the operation of umask(2)
    and bitwise arithmetic that they extrapolated any collection of bits
    with orthogonal meaning as a "mask".  I've been slowly cleaning the
    same abuse of terminology out of groff's code and documentation.
signature.asc (application/pgp-signature, 833 B)