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 _______________________________________________ xslt mailing list, project page http://xmlsoft.org/XSLT/ [email protected] http://mail.gnome.org/mailman/listinfo/xslt
