According to the de facto standard, `AWAY :\r\n` is equivalent to `AWAY\r\n`.
Our behavior was inconsistent before, now it consistently matches the de facto
standard.
See 69448b13a1 / #1969; the compiler can now ensure that a uint64
intended for atomic access is always aligned to a 64-bit boundary.
Convert atomic operations on uint32s and pointers as well.
On a 32-bit architecture, 64-bit atomic loads and stores must be aligned to a
64-bit boundary. Since the (mysql.MySQL) struct is directly included in the
Server struct, it is impossible to guarantee this via the standard technique
of putting the 64-bit value at the beginning of the struct definition
(since the point at which it is included in the parent struct may cross a
64-bit boundary).
This optimization is probably pointless anyway, adding an additional
indirection won't make a difference.
NS SAREGISTER should send machine-readable responses. A simple approach:
check if the account-registration cap is enabled, and if so, send the
the same responses that would be sent by the REGISTER command.
`NICK :` pre-registration needs to be special-cased to immediately
send ERR_NONICKNAMEGIVEN (unlike erroneous nonempty nicknames,
which are processed when registration is complete)
If the nickname must equal the account name (because always-on or
force-nick-equals-account), the correct error response to an empty
or otherwise invalid nickname is the usual "You must use your account
name as your nickname".
DEFCON 4 and lower were blocking SAREGISTER. This is wrong; admins should be
allowed to make new accounts even under DEFCON (this may be needed
specifically to work around the DEFCON restriction).