[MacPorts] #65491: clex @4.6.patch10: implicit declaration of functions

[MacPorts]

#65491: clex @4.6.patch10: implicit declaration of functions
------------------------+--------------------------------------
  Reporter:  bryanchow  |      Owner:  ryandesign
      Type:  defect     |     Status:  accepted
  Priority:  Normal     |  Milestone:
 Component:  ports      |    Version:  2.7.2
Resolution:             |   Keywords:  catalina bigsur monterey
      Port:  clex       |
------------------------+--------------------------------------

Comment (by ryandesign):

 The fix is not as simple as just including a missing header. The
 undeclared functions being referenced here are wide-character functions
 declared in curses.h, and clex's inout.c does already include that header.
 The problem is that wide-character functions are only declared by ncurses
 if `NCURSES_WIDECHAR` is nonzero. If it is not already defined, ncurses
 defines `NCURSES_WIDECHAR` to 1 if `_XOPEN_SOURCE_EXTENDED` is defined or
 if `_XOPEN_SOURCE` is greater than or equal to 500 (otherwise it defines
 `NCURSES_WIDECHAR` to 0) and neither of those seem to be the case here.
 clexheaders.h does define `_XOPEN_SOURCE` to 600 but only on system that
 are not macOS nor FreeBSD. This is probably because defining
 `_XOPEN_SOURCE` can have wide-ranging unintended side-effects because if
 it is defined then the system headers alter which functions are available
 depending on the value of that define. I tried building on macOS 10.15
 with `_XOPEN_SOURCE` defined to 500 or 600 and it failed with implicit
 declaration of function `strsignal`. That's fixed by defining
 `_XOPEN_SOURCE` to 700 but then I still have implicit declarations of
 functions `major` and `minor`. Better perhaps not to mess with
 `_XOPEN_SOURCE`.

 Defining `NCURSES_WIDECHAR` to 1 seems to be to be the least invasive
 solution since this define is specific to ncurses and the functionality we
 want to enable, and doing that does work for clex in MacPorts. But this
 workaround is probably not general enough for the developers of clex to
 rely on themselves. For one thing, there are implementations of curses
 other than ncurses which would not respond to that define. And not even
 all versions of ncurses do. MacPorts ncurses does because it is version
 6.3; this define was introduced in
 [https://github.com/mirror/ncurses/commit/cf94c7485f7b40ff7870b5bf9a65e7ab87481a76
 ncurses 5.7 patch 20100403]. But even macOS 12.2.1 still ships with the
 ancient ncurses 5.7 patch 20081102 so it does not support this define. It
 does still support the `_XOPEN_SOURCE_EXTENDED` define. That was not a
 define I was familiar with before today, but it looks like the only system
 header that uses it is curses.h so setting it is probably a safe
 workaround, and doing that does allow clex to build successfully with
 either MacPorts ncurses or macOS ncurses so that's the solution I'll
 commit and I'll pass it on to the developers.

 More on how programs are supposed to enable ncurses wide-character support
 is available in the [https://invisible-
 island.net/ncurses/man/ncurses.3x.html#h2-ALTERNATE-CONFIGURATIONS ncurses
 documentation] under the `--enable-widec` configuration option (which the
 MacPorts ncurses port uses).

-- 
Ticket URL: <https://trac.macports.org/ticket/65491#comment:4>
MacPorts <https://www.macports.org/>
Ports system for macOS