| Commit message (Collapse) | Author | Age |
... | |
|
|
|
| |
Oops! Clients could get pounce to quit if they didn't send a message.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Otherwise, the result of strncmp gets converted size_t, since size_t
has greater rank than int.
Since wordcmp is only ever used as a boolean condition, this poses
no real issue, but presumably, it is meant to behave like the other
*cmp function and return a value less than, equal to, or greater
than 0 depending on the result of the comparison.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Otherwise, each source file that includes the header gets its own
definition, and according to the C standard (C99 6.9p5):
> If an identifier declared with external linkage is used in an
> expression (other than as part of the operand of a sizeof operator
> whose result is an integer constant), somewhere in the entire
> program there shall be exactly one external definition for the
> identifier
Most compilers use the .bss section for zero data, but if it uses
.data instead, or if -Wl,--warn-common is used, this will cause a
linking error.
|
| |
|
|
|
|
|
| |
I don't know what I was thinking. I'm expecting a number less than 1000
of course that fits in int.
|
| |
|
| |
|
|
|
|
|
| |
I think it's fine to keep it separate since it's a core function of the
bouncer.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Channel names can contain '!' so splitting the whole message on it won't
work.
I hate this code though.
|
|
|
|
| |
I really want to be writing tests for these functions...
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
The list that I've defined are the ones that I expect to be able to
enable probably without any clients breaking... And of course
server-time which pounce implements itself.
|
| |
|
|
|
|
|
|
| |
Turns out I did eventually fix this, because I may want to implement
"passive clients" for logging or notification stuff, which wouldn't
affect AWAY status either.
|
|
|
|
|
| |
GCC hates declaring static consts in headers and not using them, for
some stupid reason.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
> Notwithstanding any other provision of this License, if you modify the
> Program, your modified version must prominently offer all users
> interacting with it remotely through a computer network (if your version
> supports such interaction) an opportunity to receive the Corresponding
> Source of your version by providing access to the Corresponding Source
> from a network server at no charge, through some standard or customary
> means of facilitating copying of software.
This potentially means that every freenode user, for example, is
interacting with this software, and offering the corresponding source to
each of them is an unreasonable burden.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
GNU doesn't implement memset_s, but both FreeBSD and GNU implement
explicit_bzero. Darwin doesn't, so #define it in terms of memset_s.
|
|
|
|
|
|
|
| |
Clients are generally not going to send huge amounts at a time, and IRC
messages are limited to 512 bytes. If in the future we supported message
tags from clients, which have a size limit of 8191 bytes, this would
unfortunately have to be set much higher.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Prevent creating a ring consumer without authentication.
|
| |
|
|
|
|
|
| |
During registration, no other commands should be sent. Afterwards, only
intercepted commands will get parsed.
|
|
|
|
| |
OwO
|
| |
|
| |
|
|
|
|
| |
To disambiguate clientRecv and clientRead, say clientConsume.
|
|
|
|
| |
It's still messy but it works!!
|
|
|
|
|
| |
Does zeroing that extra 4K really matter? I'd rather not have
uninitialized reads.
|
| |
|
|
|
|
|
| |
I figure I'll actually use POLLOUT on clients so should never have
issues.
|
| |
|
| |
|