On Mac OS X 10.7 Lion, this fixes
In file included from .../contrib/MacOSX/../../src/ngircd/client.c:28:
/Developer/SDKs/MacOSX10.7.sdk/usr/include/netdb.h:272:13:
error: expected identifier or '('
The default of "PAM" is "yes" when ngIRCd has been configured to use it,
so show the correct default value in the sample configuration file.
Closes#119.
If gai_strerror() isn't available, use a macro that simply returns
a static error message (regardless of the real error code).
For example, GNU libc 2.0.7 doesn't implement gai_strerror().
This fixes the problem that ngIRCd can't do any IDENT lookups because
of the socket has already been closed in the child process.
The bug has been introduced starting with ngIRCd 17 ... :-(
(commit ID 6ebb31ab35)
- User mode "R": indicates that the nick name of this user is "registered".
This mode isn't handled by ngIRCd itself, but must be set and unset by
IRC services like Anope.
- Channel mode "R": only registered users (having the user mode "R" set)
are allowed to join this channel.
DEBUG_BUFFER is off by default and therefore disables these messages:
- "Handle_Write() called for connection XX, YY bytes pending ..."
- "Connection XX: ZZ bytes left in read buffer."
* ServerMode:
Handle channel user modes 'a', 'h', and 'q' from remote servers
Handle unknown channel modes on server links
Handle unknown user modes on server links
IRC_MODE(), Client_Mode(): code cleanup [2/2]
Enlarge client user mode buffer, reduce client flags buffer
Infom clients when other servers change their user modes
IRC_MODE(), Client_Mode(): code cleanup [1/2]
Xcode requires Mac OS X 10.6 or newer; Xcode 4 supports this project
format as well, so effectively you can use Mac OS X 10.6.x or 10.7.x
for building ngIRCd with the Apple Xcode IDE.
These channel user modes aren't used for anything at the moment, but
ngIRCd knows that these three modes are "channel user modes" and not
"channel modes", that is that these modes take an "nick name" argument.
Like unknown user and channel modes, these modes are saved and forwarded,
but ignored otherwise.
We have to enlage our user mode buffer, so we can handle even unknown
user modes in the future; and reduce the client flags buffer, because
I can't imagine why we ever would need ~100 flags!?
Now we support up to 15 user modes (was: 8) and up to 15 flags (was: 99).
So in the end, we even save 99-15+8-15=77 bytes for each client structure!
Alexander Barton