Hello Bill! On Sat Jan 31, 2026 at 18:02:01 GMT +01, Bill Gray wrote: > PDCurses lacks combining characters, so CCHARW_MAX = 2 would > actually be a safe value. (One wchar_t for the actual character, plus > a '\0' terminator.)
Good to know! > PDCursesMod does have combining characters and lacks an upper limit; Actually, looking through the implementation of getcchar() in PDCursesMod the limit appears to be 20. It's undocumented and might change at any time (implementation detail). Why is this important? I am not even interested in the wchar_ts. But the getcchar() API does not allow me to ignore them. If I allocate too few wchar_ts, I risk buffer overflows. > However, looking at your example, it seems to me that any curses > implementation that has getcchar( ) ought to define CCHARW_MAX. Good idea. Could you add it to PDCursesMod? Regarding NetBSD curses, I checked again: While they allocate CURSES_CCHAR_MAX (8) wchar_ts in cchar_t, getcchar() actually appears to respect CCHARW_MAX. But then they null-terminate the array 1 element beyond that, so for NetBSD curses, you actually need to allocate CCHARW_MAX+1 elements. The same would be true when first querying the number of characters with getcchar(&c, NULL, ...). But then, it appears that on NetBSD, color pairs are always encoded into the attributes via COLOR_PAIR() anyway and they allocate only 9 bits. So you can't actually have the full 15 bits as in ncurses and the 9 bits it allocates could be extracted with PAIR_NUMBER(winch(w)) as well.. @Bill Gray But then looking at PDCursesMod, that's exactly what you are doing as well. You are reserving PDC_COLOR_BITS bits for the color pair which is >= 15 only on systems with 64-bit chtype. You could also have as little as 5 bits. So not even 8 bits is a given. You should be explicit about such restrictions in the documentation. Seriously, I don't know what to make of this. Since I also need to know the maximum number of pairs I'd need a few ifdefs per curses implementation including secret knowledge about implementation details or undocumented macros... Best regards, Robin -- @ii._._.*.._+__.+_+.+...+.+.++..+*+.+._.+...*_*.*.__+__._._.++..+_*.++__+__ .+_..*...+.+_+__.+._.+...*_+_+__._ ...*_ +.+._.+.._+*+_+__._._ .+_..+.+***_ . *_+_+__.+.*.++..+_+.*.__+_ _.+...*_*_+__.++*.+...++..+* +.+.._+__._+_.+.. .++..+*_.*...+*+.+.*_ +*+i2^rj.u#__%uu#_.%uu#_+%uu#_*!+!0a"t1010^t^c^c'0a^# 1010"=d'0a-100000"=d'0auuqq*100+q[_^euu]uq-rq:^/100@oo,+,+,+oqq^t0uq@o*+*!!
signature.asc
Description: PGP signature
