Subject: Re: BIND for secondary zone dumps core.
To: Lars-Johan Liman <email@example.com>
From: Greywolf <firstname.lastname@example.org>
Date: 07/10/2001 09:19:09
On Tue, 10 Jul 2001, Lars-Johan Liman wrote:
# > AXFR == allow-transfer?
# (No, AXFR is the abbreviation for the resource record code (like SOA,
# or NS, or A) that the client sends to the server to request a zone
# transfer (copy from master to slave), and it's short for Asynchronous
# Zone Transfer (Asynchronous zone X-FeR). So you allow or disallow such
# requests to be honoured, thus allowing or disallowing AXFR.)
Man, the timezone difference is just killing the communication, here :-)
# > I don't know that I can do that from his domain, but I'll ask him.
# Later mail from Mark Andrews (netbsd-users) shows that this seems to
# be a known compiler bug, so I'll sit back and ask you to recompile
# according to his instructions (you probably alread did), and see if
# that works for you. If so, then you can turn off (and ask your friend
# to turn off) "allow-transfer" to my IP#. If not, we'll have to start
# over again. ;-)
Yep, I recompiled and all is well.
I need to construct a patch to the makefile for named to insure that
optimisation is disabled.
My question is, is this a compiler *bug* or is it a feature gone wrong
(i.e. it's doing an optimization that works in every other program
in the known universe and this chunk of code just _happens_ to trigger
it in such a way)?
If it's a feature gone wrong, is this a coding stylistic issue that is
causing the failure in optimized mode? Could it be worked around?
I'm just curious, not trying to cause a problem with this, but if this
has been a known issue with BIND vs. the compiler, why in the world hasn't
the Makefile for it already been patched to force -O0? I mean, does nobody
else out there do secondary zone transfers?
NetBSD: The power to Connect