Control: tags -1 upstream fixed-upstream On Sun, 2019-04-07 at 15:52 +0100, Etienne Dechamps wrote: > What's really weird is that the returned error code is always identical to > the number of bytes written to the output. > This bug seems to only occur if --omit-decl is used. That's very observant of you; I've investigated this and found that XMLStarlet's new maintainership has fixed this issue accidentally. Here's where it comes from.
In xml_format.c as shipped by Debian, there's a branch inside the foProcess()
function that is buggy:
> if (!ops->omit_decl) {
> /* ... this code isn't run, because ops->omit_decl is true */
> } else {
> /* ... */
> int ret = xmlOutputBufferClose(buf);
> return ret;
> }
This 'ret' variable becomes the exit status of the process, and depending on
how big it is, it may seem strange when its least-significant eight bits are
used as the exit status in a shell.
The reason why is that the foMain() function effectively contains
> int ret2 = foProcess(&ops, start, argc, argv);
> return ret2;
so the return value from xmlOutputBufferClose() propogates to foProcess(),
which propogates to foMain(), and ultimately this becomes the exit status of
the process, because xml.c defines the actual main() function which has
something like
> if(!strcmp(argv[1], "format")) { /* in other words, we've specified we want
> the 'format' command */
> int ret3 = foMain(argc, argv);
> } else {
> /* not taken... */
> }
> exit(ret3);
So xmlOutputBufferClose()'s return value is used as the exit status, but is
this a wrong thing to do? I believe so, and unless there's been an API break at
some point (quite likely with libxml2, to be fair), XMLStarlet has been
mistaken to use the code this way:
https://gnome.pages.gitlab.gnome.org/libxml2/html/xmlIO_8h.html#a36fe9cce2bb1dff29f251a993ccb745c
> int xmlOutputBufferClose (xmlOutputBuffer *out)
> Description: flushes and close [sic] the output I/O channel and free up all
> the associated resources
> Returns: the number of byte [sic] written or a negative xmlParserErrors code
> in case of error.
The new code at
https://github.com/xmlstarlet/xmlstarlet/blob/master/src/xml_format.c has been
largely tweaked and doesn't have this problem anymore, even if this was fixed
unintentionally.
signature.asc
Description: This is a digitally signed message part
