Use 'beforedepend' instead of '.depend' to hang automatically-generated
headers off.
XXX the latter is bogus without a 'beforeall' target and explicit ordering
of dependancy generation for targets.
lifetime of the call, just like the old implementation did. Previously,
we were only eating them if the application did not call sleep()/usleep()
with SIGALRM masked.
Submitted by: ache
and forgot what I was trying to do originally and accidently zapped
a feature. :-] The problem is that we are converting a counted buffer in
a malloc pool into a null terminated C-style string. I was calling realloc
originally to shrink the buffer to the desired size. If realloc failed, we
still returned the valid buffer - the only thing wrong was it was a tad
too large. The previous commit disabled this.
This commit now handles the three cases..
1: the buffer is exactly right for the null byte to terminate the
string (we don't call realloc).
2: it's got h.left = 0, so we must expand it to make room. If realloc
fails here, it's fatal.
3: if there's too much room, we realloc to shrink it - a failed realloc
is not fatal, we use the original buffer which is still valid.
Dmitrij Tejblum <dima@tejblum.dnttm.rssi.ru>
Various cleanup from Keith Bostic
Reinstate calloc() as a separate funtion, in its own source/object file.
leave the manpage integrated with malloc.3 and friends. Too many things
were broken in this respect.
PR: 4002
Reviewed by: phk
Submitted by: Dmitrij Tejblum <dima@tejblum.dnttm.rssi.ru>
Submitted by: Keith Bostic <bostic@bostic.com>
Only call malloc() if the fd is too big for the compiled in fd_set size,
and don't use calloc either. This should reduce the impact of conflicts
with private malloc implementations etc. When using the fd_set on the
stack, only zero what is needed rather than all 1024 bits like FD_ZERO did.
Various portability and stylistic cleanups.
Kill MALLOC_STATS & the 'D' option.
Fix the 'V' option.
Major overhaul of the man-page.
You milage should not vary.
Reviewed by: Keith Bostic <bostic@bostic.com>
Submitted by: Keith Bostic <bostic@bostic.com>
The logic in get_myaddress() is broken: it always returns the loopback
address due to the following rule:
if ((ifreq.ifr_flags & IFF_UP) &&
ifr->ifr_addr.sa_family == AF_INET &&
(loopback == 1 && (ifreq.ifr_flags & IFF_LOOPBACK))) {
The idea is that we want to select the interface address only if it's
up and it's in the AF_INET family. If it turns uout we don't have
such an interface available, we make a second pass through the loop,
this time settling for the loopback interface. But the logic inadvertently
locks out all cases when loopback == 0, so nothing is ever selected until
the second pass (when loopback == 1).
This is changed to:
if (((ifreq.ifr_flags & IFF_UP) &&
ifr->ifr_addr.sa_family == AF_INET) ||
(loopback == 1 && (ifreq.ifr_flags & IFF_LOOPBACK))) {
which I think does the right thing.
This is yet another bogon I discovered during NIS+ testing; I need
get_myaddress() to work correctly so that the callback code in the
client library will work.
Mike Smith
Andrey A. Chernov
Poul-Henning Kamp
John Polstra
Peter da Silva
Philippe Charnier
Bruce Evans
David Nugent
Peter Wemm
Satoshi Asami
Adam David
Jordan K. Hubbard
Tor Egge
John Hay
Steve Price
Bill Paul