Fixing build with ncurses-5.9 (#4800) broke shadows

[egmontkob]

Is there an existing issue for this?

• I have searched the existing issues

Midnight Commander version and build configuration

a5909f24b800fbac51a7f8049eddaf9a960ebee1

Operating system

all

Is this issue reproducible using the latest version of Midnight Commander?

• I confirm the issue is still reproducible with the latest version of Midnight Commander

How to reproduce

No shadows on ncurses-6.5 after the said commit / PR.

Ossi correctly pointed out during review that the condition is fishy; it is indeed broken.

I assume that in ncurses itself, where this was taken from, something else is going on. Widec support might already be enabled and he's just gathering a few more conditions when it also needs to be enabled; or something like that.

(Also, in my pending PR 4813, line characters break if I apply this same change.)

Expected behavior

.

Actual behavior

.

Additional context

No response

[egmontkob]

Common sense tell me that there are 4 possibilities:

• VAR is undefined => not supported
• VAR is defined to 0 => not supported
• VAR is defined to 1 => supported
• VAR is defined to empty => ???

---

If empty means not supported then you could do:

#if defined(VAR) && (VAR - 0 > 0)

(or == 1 or >= 1 etc.).

This is quite obvious; if VAR is empty then lhs becomes - 0, if VAR is 0 then it becomes 0 - 0, both are zero.

---

If empty means supported then it becomes trickier. I've found two possibilities to distinguish empty from 0:

https://stackoverflow.com/a/48540034:

#if (0-VAR-1) == 1 && (VAR-0) != -2
VAR is empty
#endif

https://stackoverflow.com/a/48361345:

#if ~(~VAR + 0) == 0 && ~(~VAR + 1) == 1
VAR is empty
#endif

[horkykuba]

This conditional comes from a very specific case in the ncurses code, where it serves an entirely different purpose (allowing some wide char processing in test suites even when NCURSES_WIDECHAR=0). Furthermore, NCURSES_WIDECHAR can't be used to check for the wide/non-wide ncurses library at all - its value depends solely on the definition of the feature test macros (_XOPEN_SOURCE macros).

So I suggest removing it in #4822. Currently, the mc code can't work with non-wide ncurses.

Btw, sorry for not linking it to this issue - I didn't notice at all :)

[egmontkob]

Currently, the mc code can't work with non-wide ncurses.

This is not really true, see #4822 (comment).

Furthermore, NCURSES_WIDECHAR can't be used to check for the wide/non-wide ncurses library at all

Yup, this is right. NCURSES_WIDECHAR is defined to 1 even when compiling against the narrow char version. So the fix will have to be a little more different.

Is there a built-in ncurses define that we can rely on? Or if not then I guess ./configure could try to build a test code compiling some widechar-specific feature and based on that set a custom define for us.

[egmontkob]

A lot might depend on how the vendor / distribution packages it.

Manually compiling latest ncurses with --enable-widec vs. --disable-widec, they install different header files. The narrowchar variant still seems to identically define NCURSES_WIDECHAR, but does not declare wide char functions like add_wch().

On Ubuntu 25.10, however, the entire /usr/include/ncursesw directory is just symlinked back to the files directly under /usr/include, so it's the same set of headers installed.

Seems to me that upstream ncurses was designed to install either the narrow or the wide variant, but not really for installing both in parallel, that's probably done differently by every vendor.

So even if ncurses header files clearly defined something denoting wide char support (e.g. we could #ifdef WACS_HLINE), it'd be broken on Ubuntu as it's even defined (although unusable) with the narrow char headers.

I think our only chance is: During ./configure, try to compile something relying on some widechar function (e.g. an add_wch(WACS_HLINE) just to test both a function and a constant) and see if it succeeds.

@zyv You're an autoconf magician, could you please take care of this? It would be great if both horkykuba and me could rebase our work on top of that.

[egmontkob]

Or, wait... could we just go for #ifdef WACS_HLINE or similar, I'm wondering?

Systems that only have the narrow version won't see this define at all.

If a system sees this define then it has the wide char variant installed somewhere. And then it's probably safe to assume that pkgconfig will let us locate that installation and not the narrow char one, even if both are installed in parallel.

This will break if our configure finds the widechar headers but the narrowchar actual library. In which case it might even be better to fail than to silently use the narrowchar version, forcing the user to investigate and find how to get to the preferred (widechar) build.

[egmontkob]

We already test addwstr() in m4.include/mc-with-screen-ncurses.m4 which in turns appears in ./configure. If it fails then we print

checking for addwstr... no
configure: WARNING: NCurses(w) library found without wide characters support

Could this test also result in some #define that we can use later?