GNOME Bugzilla – Bug 319822
Although I give FILE to xsltSaveResultToFile, it always return error.
Last modified: 2009-08-15 18:40:50 UTC
xsltSaveResultToFile needs FILE parameter which opened file to output. So I called "fopen" but xsltSaveResultToFile caused error. Why ? Does iconv have an bug(about reading file)? Although I'm looking for the example to use xsltSaveResultToFile, it is not anywhere. As an example,there is always only xsltSaveResultToString. Since I have to transform XML(200MB),I can not use a function like xsltSaveResultToString which truly consumes a memory. int Transform0(const char* input_xmlname, const char* transform_xsl, const char* out_htmlname) { xsltStylesheetPtr style = NULL; xmlDocPtr xmldoc,res; FILE* html; const char *params[16 + 1]; char* buf; int size; xmlInitParser(); params[0] = NULL; params[1] = (char*)"-o"; params[2] = (char*)out_htmlname; params[3] = (char*)transform_xsl; params[4] = (char*)input_xmlname; params[5] = NULL; xmlSubstituteEntitiesDefault(1); // 0 ? xmlLoadExtDtdDefaultValue = 1; xmlIndentTreeOutput = 1; //defaultLoader = xmlGetExternalEntityLoader(); //xmlSetExternalEntityLoader(xmlMyExternalEntityLoader); html = fopen(out_htmlname, "w"); //html = fopen(out_htmlname, "ab"); if(html==NULL) return(-1); exsltRegisterAll(); style = xsltParseStylesheetFile((const xmlChar *)transform_xsl); if(style==NULL) { fclose(html); return(-1); } xmldoc = xmlParseFile(input_xmlname); xmlXIncludeProcess(xmldoc); if(xmldoc==NULL) { fclose(html); return(-1); } params[0] = NULL; res = xsltApplyStylesheet(style, xmldoc, params); if(res==NULL) { fclose(html); return(-1); } xsltSaveResultToFile(html, res, style); //xsltSaveResultToString((xmlChar **)&buf, &size, res, style); fclose(html); xsltFreeStylesheet(style); xmlFreeDoc(res); xmlFreeDoc(xmldoc); xsltCleanupGlobals(); xmlCleanupParser(); return(0); }
Please attach a small xml and a small xsl file which produce the error. Bill
*** Bug 319821 has been marked as a duplicate of this bug. ***
xsltSaveResultToString is OK ,so xml and xsl is not wrong. xsltSaveResultToFile is strange and I don't know how to call that and have not seen the sample codes yet. I am sorry, xml and xsl cannot be exhibited because of the reference documents of the ban on public presentation.
OS == Windows !!!! That's the crucial information provided only in the last comment ! If libxml2/libxslt were compiled with compiler A options a and you are compiling your app with compiler B option b then if A != B or a != b: usually all FILE * just don't work => triple check your tools chains this is very unlikely to be a GNOME issue => xsltproc uses xsltSaveResultToFile. If xsltproc works with your input documents then the problem is on your side 99.9% garanteed it's a compilers problem disagreeing on what/how a FILE * should be implemented. Daniel
Um... Does a compile option influence FILE? I thought FILE was the runtime library of C to the last.
except different compilers have different own representation of them ! And it's getting clear that any change of compiler option can generate incompatibilities on Windows. I have seens just too many Windows users getting toast by this. Daniel
How is what is necessary just to carry out a compile option, when making the Windows application using the binary (DLL) distributed now, if it becomes? Although I think that the option which can be used has restriction...
I don'tunderstand your last comment. It is relatively clear the bug is at the level I suggested. Verify xsltproc.exe work on your platform, it uses the same call. Beyond that it is not a GNOME releated problem, nor anything I can debug/reproduce or in general help with. Asking further informations about behaviour in this case just can't get an answer, try to ask on the mailing-list, if you want but from a bugzilla.gnome.org point of view this is closed as outside our area of expertise and dependant on non-gnome parameters. Daniel