- config.guess: 2020-04-26 - config.sub: 2020-05-04 And set both scripts +x, they are executable.

Change the line buffer in the Read_TextFile() function from 127 to COMMAND_LEN (=512) bytes. Lines can't even get that long, because they have to be prefixed before being sent to the client, so this is a sane maximum. This allows for even more "fancy" and "wider" MOTDs :-) Closes #271.

Don't show the static list of all possibly available channel types ... Closes #273.

- Add x86_64/apple/darwin19.0.0 (Apple clang 11.0)

- Update powerpc/apple/darwin8.11.0 (gcc 4.0.1) - Add mips/sgi/irix6.5 (SGI C compiler) - Add mipsel/unknown/netbsd8.0 (gcc 5.5.0) Thanks to Götz Hoffart <goetz@hoffart.de>!

Don't use the "standard" IRC SSL port 6697, as this easily collides with real (ng)IRCd instances running on the same machine. And by reusing port 6790, which is already used by the "test server #2", we don't need any other port than the test suite already uses.

Add support for GnuTLS certificate reload. Thanks a lot, Hilko Bengen!

Not sure about the portability of strpbrk() in really ancient OS, and this was the only place where it became used recently in ngIRCd ... So let's play it safe! ;-)

The DH parameters reference has to be stored next to the x509_cred which holds a reference to it.

There is no point in waiting up to one second for the network receiving new data when there is still a read buffer holding at least one command; we shouldn't waste time but handle it immediately!

This requires keeping track of currently active certificates, so those are stored separately, along with a reference counter, and discarded when they are no longer in use.

If there are more bytes in the read buffer already than a single valid IRC command can get long (513 bytes, COMMAND_LEN), wait for this/those command(s) to be handled first and don't try to read even more data from the network (which most probably would overflow the read buffer of this connection soon).

No longer mention "[Channel]->Key" and "[Channel]->MaxUsers".

No functional changes.

This requires some changes to the build system, for example to comply with the expectations of the GNU autoconf/automake tools ...

This reverts commit c6e3c13f27744971fcb1d2de4e561d3bcdaa5aed. This sounded like the right approach at first, but I'm not that sure that it really makes sense to have different sizes of read buffers: the per-connection read buffer only needs to keep data that is needed to parse one full command, be it plain text, encrypted and/or compressed. Then ngIRCd should handle this one command, move leftover data to the beginning of the buffer and read the next chunk from the network that is missing to get the next complete command (512 bytes at max). So I revert this for now and try to fix the logic in Read_Request(), which is broken nevertheless, as it results in servers becoming disconnected during "server burst" when "big" lists are transferred.

The name of the Config_Error() function is misleading: it is not only used to show configuraton errors, but all messages shown during normal operation as well as for "config testing": it takes care of the correct formatting of the messages (syslog, forground logging, config testing). This fixes commit bb1d014abad8.