patch to remove deprecated operators

Kevin Oberman oberman at
Mon Mar 31 21:18:08 UTC 2008

> Date: Mon, 31 Mar 2008 11:21:24 -0700
> From: bill fumerola <billf at>
> Sender: irrtoolset-bounce at
> S.P.Zeidler wrote:
> > Hi,
> thanks for chiming in here, extensive conversations took place after my
> post, but they were all made off-list by ISC and previous authors and/or
> maintainers.
> > I've used trigraphs instead of max; that's in the 'whatever looks prettier
> > to you' category I'd say. :)
> certainly. i didn't need to use the std::, since that namespace was already
> in play. i used it to make it more obvious. using a trigraph is an equally
> proper way to address the logic. i just wanted a more 1:1 change, a max
> operator was used, now a max method is used. native operator -> operator may
> be more of a properly limiting change.
> the only concern i never followed up on was differences between the equiv
> case and if there was an order-dependent difference in the 'winner' between
> gcc's >?, std::max. yours certainly looks to behave in the same manner.
> >
> > contains my current proposal for the next IRRToolSet version. Comments?
> the patch would be more straightforward without including generated content
> (the and changes - they're distracting unless you've modified
> them post-generation, have you?). i understand that for netbsd ports, this
> is likely done to avoid build dependencies. IMO, if users want to avoid
> build dependencies they should use packages. anyways, the patch is certainly
> thorough and contains everything submitted in mine either exactly or in spirit.
> besides the generated grammar/parser, the rest of the changes (casts, proper
> includes depending on gcc version, changing the manpage Errors to have a
> proper prefix, asnum_string(), etc) all look good to me. the bug-fixes look
> right, but i haven't reviewed the code path. considering the source, i trust
> them.
> > ISC as maintainer would of course pick up patches as they saw fit.
> working with that maintainership has been confusing at best.
> i'm reluctant to disclose direct quotes out of because of netiquette.
> in private mails, ISC has given me the impression of many different
> positions of (all paraphrased) "why change it?", "won't fix until gcc
> actually breaks it", "not interested in a method for community submitted
> patces", "punt this software out of ISC to sourceforge/RIPE/etc", "fixing
> non-bug warnings are not important and/or could offend the original
> authors", "the toolkit does everything it's supposed to adequately".
> had ISC kept this mailing list in the loop of my thread, i think the members
> of this list would be astonished at how disinterested (or at least
> apathetic) the ISC maintainer is. disinterest in the submission of the
> simplest of patches (#include, etc) and all the way up to offers of more
> complex code contributions.
> one thing is clear to me now - IRRToolSet is not a community project - it is
> an ISC project. i don't know how this was handled when it was an ISI or RIPE
> project. i'd love to hear a clarifying position from ISC on my suggestions
> on how to improve community involvement. one way or another, i'd like to
> know what the proper terms of engagement are with this project for upstream
> patches submitted to the vendor.
> this isn't BIND or INND. ISC isn't making revenue from support and
> customizations of IRRToolSet as they are with other software. i understand
> the closed nature of the other projects. this shouldn't extend to IRRToolSet.
> ... and this whole saga has taken up more of my time per line of code than
> any other upstream vendor i've ever dealt with.
> -- billf (, but not the freebsd ports maintainer of IRRToolSet)


I have been dealing with IRRToolSet and its former self, RAToolSet since
they came into existence. Back when Cengiz was working on it, I get
excellent support for things like Alpha Tru64 support. 

When his grant ran out, RIPE took over. It took me months to get in
touch with anyone at RIPE who would acknowledge any patches. It mostly
just sat unwanted orphan. When it want to ISC, the patches to
make it build with gcc V3 finally went into the code base. I had been
using these for some time and they had been in the community even
longer, but it took a long time to actually get them into the base. It
is not clear to me whether they went in just before the code went to ISC
or just after.

For a while, I had sporadic good results getting ISC to patch things and
a promise that updates for gcc v4 were being worked. That was about a
year ago and, since then, silence. I hate having a port with a USE_GCC
line it it. I just don't have any better way to go.

By the way, I am just a network engineer who needs IRRToolSet for his
job. I am a weak C coder and hopeless with C++, so I can only try things
and, it the work, include them in the port. The FreeBSD port does
produce a cleaner documentation than the ISC build as a result of
trivial patches to the documentation that ISC has never gotten around

It looks like they fit under the heading of general cleanup. If you and
spz can arrive at a common patch set, that I will do some testing and,
if their is no major objections from folks on this list, will submit them
to ports at .

I really hope this does not lead to a fork of the code, but, if ISC does
not do something, if does no good sitting there with the bits rotting.

I'll try to talk to vix next time I see him, but he and I tend to attend
different meetings these days. (I'd like to see him back at NANOG
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 224 bytes
Desc: not available
URL: <>

More information about the irrtoolset mailing list