Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Ncurses declaration compatibility (52383 vs. 52398+)
- X-seq: zsh-workers 52435
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: Zsh hackers list <zsh-workers@xxxxxxx>
- Subject: Ncurses declaration compatibility (52383 vs. 52398+)
- Date: Sat, 30 Dec 2023 21:10:20 -0800
- Archived-at: <https://zsh.org/workers/52435>
- List-id: <zsh-workers.zsh.org>
We have competing patches for configure failures in the face of
gcc -Werror=incompatible-pointer-types
Florian (52383) simply cast away the error in the configure script,
because the const-ness is inconsequential to Src/Modules/curses.c
usage of the arrays.
Nicholas (cf. 52398) did extra work for const correctness in the Src
code as well, but made some stylistic choices that Oliver and I found
superfluous or unhelpful.
To supply some context Nicholas did not have, users/13418 introduced
the "zstrcodes" variable because a Cygwin compiler in 2008 had issues
with (re)declaring "strcodes". However, zstrcodes was described as a
"hack" that would have been better corrected by diagnosing the reason
configure choked on strcodes. This was never done. Aside from
Oliver's stylistic objection to the use of #defines, enshrining an old
hack by changing the handling of all the other ncurses arrays to match
it, seems a step in the wrong direction.
Any volunteers, with Cygwin access, to back out users/13418 and
determine if strcodes is still broken after 15 years?
Messages sorted by:
Reverse Date,
Date,
Thread,
Author