This trivial diff gets rid of noisy warnings such as
```
./src/common/ignore.c:274:13: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]
274 | ignore_load ()
| ^
| void
```
when building with modern clang. This is cosmetic since these functions
are actually prototyped in a header, so if the header is in scope it's
not possible to call them with an arbitrary number of arguments.
Using HMAC ()'s facility of returning the digest in a static array is
not thread safe (this can't be fixed) and it is not portable to the
OpenSSL forks: BoringSSL removed support for this a decade ago (so
aws-lc doesn't support it either) and LibreSSL followed a few years
back.
There is no downside to having a 32-byte array on the stack and it would
make zoitechat safe to use from other forks without the need of patching
it.
Add an error check for the HMAC () call and handle the error in the
caller.
When nick indentation is off, lines after the first wrap back to the
left edge, under the timestamp. Add a text_wrap_align preference
(start of line, prefix, message) so they can line up under the nick or
the message text instead. It is applied at wrap time, so existing
scrollback is re-wrapped when the setting changes, and the menu is
greyed out while nick indentation is on.
master's new xtext_tests target compiles xtext.c on its own with only
GTK linked, so hexcolor_parse cannot live in util.c. Keep it in a
dependency-free hexcolor.c that both test targets compile, and register
it in the Visual Studio project for the Windows build.
Claude-Session: https://claude.ai/code/session_01Jxd4AknGzdAENADWAGHCzx
Instead of retrieving the AlgorithmIdentifier and then reaching into it
to get the OID, the relevant OID can be obtained directly from the same
function.
Mirrors the PRIVMSG fix: replayed /me messages sent by our own nick
via WeeChat relay backlog were always passed with fromme=FALSE,
so they never got rerouted to the actual PM query window.
When you send a private message, ZoiteChat sometimes gets the same
message echoed back by the server so it can show it in the right
window. Whether it recognizes that echo depended on the server first
confirming a feature called "echo-message" during connection setup.
WeeChat's relay doesn't seem to confirm that feature the way other
servers (or ZNC) do, so ZoiteChat didn't recognize its own echoed
messages and treated them as brand new incoming messages from
yourself, opening a second, separate conversation window instead of
using the one you were already typing in.
This makes ZoiteChat recognize its own message by checking who sent
it, instead of only trusting that feature confirmation. That way,
sent and received messages always end up in the same conversation
window, regardless of how well the server/relay announces its
capabilities.
deepend
deepend-tildeclub
Theo Buehler
ThePeGaSuS
BareMetal