patch to remove deprecated operators

[S.P.Zeidler]

Hi,

Thus wrote bill fumerola (billf at opendns.com):

> > http://ftp.netbsd.org/pub/NetBSD/misc/spz/IRRToolSet-4.8.5-to-4.8.6.diff
> > contains my current proposal for the next IRRToolSet version. Comments?
> 
> the patch would be more straightforward without including generated content
> (the .l.cc and .y.cc 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.

IRRToolSet-4.8.5 contains these generated files so I provided newer
versions; pkgsrc will rebuild them since gmake etc are available so it's
not a NetBSD or pkgsrc thing, it's more a convenience to the maintainer
provided the generated files are being kept.

> IMO, if users want to avoid
> build dependencies they should use packages.

If they exist :) But in the general case, yes probably.

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

Note that lots of these changes have been supplied by other participants
of this mailing list over the last year. As maintainer of the pkgsrc
package I get challenged with making it build on eg ancient Irix too,
which is due to the (otherwise probably rather silly) pre-gcc-2 patches.

> > 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".

Well, you got an answer. Which is better than I got for offering up a
ready-rolled compilation of last years input.

regards,
	spz
-- 
spz at serpens.de (S.P.Zeidler)