Such a variable suggests that we will never read past that, but that
is not the case, since we (correctly) assume that the buffer is
NUL terminated, which is ensured by dbuf_getmsg().
The 'length' is still available for informational purposes, to avoid
strlen()'s at various places.
Hm, I guess length can cause the same confusion as bufend, but still..
I like it better :D
This also includes buffer modifications to have a larger read buffer
and IRCv3 implementations (partial or not) for:
labeled-response, msgid, server-time, batch and account-tag.
As said, it is the initial and partial implementation.
There are still various FIXME's and TODO's, the API of various
functions may still change (actually that is true for the next
months, even) and some stuff is currently in the core that will
be moved to modules.
The last parv[] array element will be NULL. Accessing any elements after
that is undefined, similar to reading past the nul byte of a string.
This poison will help catch such bugs. Without this poison your code
will also crash, now it just crashes more consistently.
* The operclass privileges have been redone. Since there were 50+ changes
to the 100+ privileges it makes little sense to list the changes here.
If, like 99% of the users, you use default operclasses such as "globop"
and "admin-with-override" then you don't need to do anything.
However, if you have custom operclass { } blocks then the privileges
will have to be redone. For more information on the conversion process,
see https://www.unrealircd.org/docs/FAQ#New_operclass_permissions
For the new list of permissions, with much better naming and grouping:
https://www.unrealircd.org/docs/Operclass_permissions
The inconsistency in the privileges was initially reported by webczat in
https://bugs.unrealircd.org/view.php?id=4771
The subsequent reorganization took two full days, so.. hopefully the
people who are using - or plan to use - custom operclasses will like the
new layout... except that they need to redo their work of course ;)
No UnrealIRCd code reads from parv[0] anymore.
Perhaps later, after a few stable versions, we'll turn this into something more useful. Or not. But not soon.
Parsing of commands based on permissions was incorret - if a command was not a user facing command explicitly, it would be denied for a user, furthermore if it was a server issuing the command, and it also was an oper command, it would be denied for similar reasons - corret parsing now in place.
This is partially for the sake of Stskeeps, even though he left the
project long ago, but mainly so we can work towards dynamic ticks in
the event loop while guaranteeing latencies for connected clients,
even with fakelag.
(HOOKTYPE_PACKET). Replacing the 'text to be sent' to a client is
supported, which allows character(set) conversion in a module.
Note that modifying an incoming message by the hook is not supported.
Bram Matthys