Ultrix patches version 2 for bind 8.2.2-P3

Paul A Vixie vixie at mibh.net
Wed Nov 17 07:01:43 UTC 1999

> I was using the "prior art" of port/irix/noop.c, and silently wondered
> why a noop.c file had something in it :)

the irix port is also wrong in this regard.  my apologies for its confusion.

> I'm not 100% sure what you're aiming for here.  I don't think we can
> unconditionally just prototype
> 	int sprintf(...);
> because it'll conflict with <stdio.h> on some systems.  Do you mean
> change all sprintf()'s in the bind code to isc_sprintf()?  Even with
> Mark's sprintf() implemenentation, we'll need to keep VSPRINTF_CHAR for
> lib/isc/logging.c, as well as the new isc_printf().
> Or have an __isc_sprintf() that only gets used when NEED_INT_SPRINTF is
> defined?  In the Ultrix case, we actually have the right prototype, just
> the wrong return value is some circumstances!

yow.  under those circumstances, let's just constrain the size of the change
as much as possible, and do what you proposed earlier -- make this ultrix-

> I looked into this further - the problem is actually in port/systype.
> Here's the 'cd' line from port/systype on /bin/sh and /bin/sh5:
> 	balrog:bind8/bind-8.2.2-P5/ultrix-src 152> sh
> 	$ cd `dirname port/systype` > /dev/null
> 	illegal io
> 	$ exit
> 	balrog:bind8/bind-8.2.2-P5/ultrix-src 153> sh5
> 	$ cd `dirname port/systype` > /dev/null
> 	$ exit
> The problem seems to be with the "cd" builtin:
> 	balrog:bind8/bind-8.2.2-P5/ultrix-src 154> sh
> 	$ cd $HOME > /dev/null
> 	illegal io
> Does the "> /dev/null" need to be there?  It looks like the port
> directory should always be there.  If I remove the redirection on
> port/systype, Ultrix gets by without needed SH=sh5.

unfortunately, there are other shells whose cd commands produce output even
when they are successful.  i think that the ultrix behaviour is wrong, but
not as wrong as the other system's behaviour of producing output, so please
remove the redirect to /dev/null and we'll let the other system fail instead.

sounds like we're very close.

More information about the bind-workers mailing list