You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by Mark Martinec <Ma...@ijs.si> on 2007/09/14 20:44:04 UTC

Re: buildbot failure in mc-fast

Justin,

> buildbot@spamassassin.zones.apache.org writes:
> > The Buildbot has detected a new failure of mc-fast.
> > Full details are available at:
> >  http://bbmass.spamassassin.org:8011/mc-fast/builds/893

> Undefined subroutine &Mail::SpamAssassin::Conf::untaint_var
> called at ... Mail/SpamAssassin/Conf.pm line 2843

Ok, reverted for that module:

$ svn -m 'Conf.pm: revert importing of untaint_var,
          anonymous subs may run in another context' ci
Sending  lib/Mail/SpamAssassin/Conf.pm
Committed revision 575772.

I wonder why self-checks and my regular usage did not notice it.
Sorry.

> by the way, I'm not sure it's a good idea to use exported functions -- in
> my opinion it's easier to track down function source code when the full
> path to their module is specified:
>     Mail::SpamAssassin::Util::untaint_var(...)
> vs.
>     untaint_var(...)

The Util.pm is already exporting local_tz and base64_decode,
so I thought exporting another frequently used sub from
a 'tools' module is not a big deal.

> Also, does this impose a memory overhead by adding "untaint_var" to the
> package-local namespace of every module that loads it?  if I recall
> correctly it does, whereas the nonexported version does not.  (I
> may be wrong ;)

I'm not aware of it, I lived under impression that just some aliasing
is done, costing few dozens of bytes, but I may be wrong. Any refs?

If cost of polluting a namespace is of concern, then the crusade
should probably start with dozens of library modules which
(through 'use') import mostly whatever is offered by default.

  Mark