patch to remove deprecated operators

bill fumerola billf at
Mon Mar 31 18:21:24 UTC 2008

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

> 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

> 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)

ps. my intention is not to make enemies with ISC, the private response to my
patch and my suggestions for community involvement in this codebase has been
so negative that i cannot logically deduce their position. keeping that
thread off the list speaks volumes. if the members of the private thread OK
it, i will forward the thread to the list.

More information about the irrtoolset mailing list