Apple has significantly changed the way `perl` is structured in macOS
Mojave/10.14, which is due to ship stable this month. The `perl`
restructuring has been an issue for a while but I recently obtained
confirmation from Apple the changes were intentional & consequently not
something that was going to be walked back before Mojave reaches its
stable release.
As of 10.14 the Perl headers are moving inside the SDK, instead of
residing in `/System` directly. There's a flag to tell Clang to look
inside the SDK without projects having to explicitly locate the SDK &
fiddle with the location themselves, which is `-iwithsysroot`, and
that's what `perl` outputs now when `configure` checks
`perl -MExtUtils::Embed -e ccopts`:
```
-g -pipe -fno-common -DPERL_DARWIN -fno-strict-aliasing -fstack-protector -iwithsysroot /System/Library/Perl/5.18/darwin-thread-multi-2level/CORE
```
The latter bit of that was previously
`-I/System/Library/Perl/5.18/darwin-thread-multi-2level/CORE`. The
problem here is that `configure` filters out flags that start with a
lowercase `i` and consequently the Perl elements fail to build. This
tiny patch fixes that issue, restoring Perl support to `irssi` when
built on macOS 10.14.
As we called the same function for the topic info numeric, we ended up
losing the topic as that numeric does not include it. We now call a
different function to handle this case more carefully. Fixes#903.
Hi folks!
I tried clang-static-analyzer on irssi 1.1.1, it seems like it
finds some things. Here's a diff, but there might be more that you would
want to check, or choose to work differently.
(in special-vars.c, ret is commands->data sometime)
I hope it's not too much trouble if reported as a confidential bug.
Thanks.
This adds a i_wcwidth() function that replaces mk_wcwidth(), and a
'wcwidth_implementation' setting to pick which one it wraps.
Values:
- old: uses our local mk_wcwidth() which implements unicode 5.0
- system: uses the libc-provided wcwidth(), which may be better or worse
than ours depending on how up to date the system is.
- auto: tests the system one against two characters that became
fullwidth in unicode 5.2 and 9.0 respectively. If either of them pass,
pick the system implementation, otherwise pick ours.
It defaults to auto.
mk_wcwidth() is still preferable in some cases, since the way it uses
ranges for fullwidth characters means most CJK blocks are covered even
if their characters didn't exist back then.
The "system" implementation is also wrapped to never return -1, but to
assume those unknown characters use one cell. Quoting the code:
/* Treat all unknown characters as taking one cell. This is
* the reason mk_wcwidth and other outdated implementations
* mostly worked with newer unicode, while glibc's wcwidth
* needs updating to recognize new characters.
*
* Instead of relying on that, we keep the behavior of assuming
* one cell even for glibc's implementation, which is still
* highly accurate and less of a headache overall.
*/
