Re: [xslt] Bug 530891

["William M. Brack" <wbrack mmm com hk>]

Ron Burk wrote:
>> do you think you will
>> spend the next week-end debugging the problem ?
>
> Could it be as simple as reversing the polarity?
> Er, I mean, adding the line shown below to functions.c?

I'm not quite clear on the significance of that beginning, but my
initial interpretation is to take it quite badly. It sounds as if this
is some sarcastic attempt to mix bugs 530891 (mentioned in the header)
with bug 541965 (atan2 arguments), and infer that the VERY few people
who try to maintain libxslt are somehow not properly performing their
DUTY to promptly address any bug submitted.  Over the past several
years, I have personally spent a very significant amount of time on
chasing bugs and trying to fix them, for both libxml2 and libxslt. 
What most people do not realize is that I have not been an active user
of either library during most of that time, but have spent this effort
as a means of "repaying" the open-source community for the great
benefits the libraries gave me in the early years.

> Seemed to fix the problem, but whether running the
> test suite inspires confidence or not, I don't know.
> I couldn't immediately spot any tests that exercise
> this function...

Assuming we are now talking exclusively about bug 530891, as a bug
chaser my first duty is to confirm that the bug is valid, i.e. is the
claim of "wrong" behaviour truly "wrong".  That means I first must
check the spec to see what is "right", so I need to look at
http://www.w3.org/TR/xslt#function-element-available. That tells me
that the function argument "must evaluate to a string which is a
QName", and then to an "expanded-name".

Now I must go to the code to see what it currently does, and whether
it's "right" or "wrong".  When I do that, I find that the code is
checking directly whether it's a string, rather then whether it
"evaluates to a string". So, this should be easy to fix.

> I'm unfamiliar with *nix customs for patch submitting,
> and the process was not immediately clear from
> the "how to help" web pages for libxslt (which seem
> to say "ask first" anyway...).

For a small change, just a reference to the line and the suggested
change is sufficient.  For something more complex, use "diff -c" to
generate a file which can be attached to either the bug report, or to
the mailing list post.

>
> void
> xsltElementAvailableFunction(xmlXPathParserContextPtr ctxt, int
> nargs){
>      xmlXPathObjectPtr obj;
>      xmlChar *prefix, *name;
>      const xmlChar *nsURI = NULL;
>      xsltTransformContextPtr tctxt;
>
>      if (nargs != 1) {
>      xsltTransformError(xsltXPathGetTransformContext(ctxt), NULL,
> NULL,
>          "element-available() : expects one string arg\n");
>      ctxt->error = XPATH_INVALID_ARITY;
>      return;
>      }
>
>      /******** ADDED THE FOLLOWING LINE  ********/
>      xmlXPathStringFunction(ctxt, 1);
>      if ((ctxt->value == NULL) || (ctxt->value->type != XPATH_STRING))
> {
>      xsltTransformError(xsltXPathGetTransformContext(ctxt), NULL,
> NULL,
>          "element-available() : invalid arg expecting a string\n");
>      ctxt->error = XPATH_INVALID_TYPE;
>      return;
>      }

Yes, that's exactly the correct fix for this bug.  But now, as a
(volunteer) maintainer, there are a few more things that need to be
done. First, are there any obvious similar places with the same
trouble? Ah, yes, there's "function-available", with exactly the same
code sequence.  So, I need to fix that as well (note this was
mentioned on the bug report).

Having edited the source, I must now confirm whether the fix cures the
bug.  I also need to check whether the fix has screwed up any of the
regression tests. It's also useful to check whether the function is
actually checked by any of the regression tests (in this case it is,
by tests/extensions/list.xsl). So, I do all of this, find it passes,
and now wind up by editing the ChangeLog, giving credit to any people
who have participated in the squashing, then commit the results to
SVN, and finally close the bug report.

So, now the bug is closed, and I have spent somewhere between a
half-hour to an hour of time that I could have spent on any of several
other projects that I am actively involved with.

Thanks for your help - I've mentioned you in the ChangeLog.


Regards,

Bill