[Crash-utility] __error() mucks with pc->tmpfile

Bruce Korb bruce.korb at gmail.com
Fri Dec 14 02:17:00 UTC 2012


I spent today trying to figure out why some parsing was going awry.
The problem stems from trying to emit a warning message while
reprocessing the pc->tmpfile data.  viz.:


        open_tmpfile();
        hq_open();
        count = do_list(&ld);
        hq_close();
        rewind(pc->tmpfile);
	while (fgets(buf, sizeof(buf), pc->tmpfile) != 0) {
		if (something_wrong(buf)) {
			error(WARNING, "something wrong");
			continue;
		}
	... etc.

After the error() invocation, the data have been scribbled on because
of this code:
        if ((fp != stdout) && (fp != pc->stdpipe)) {
                fprintf(fp, "%s%s%s %s", new_line ? "\n" : "",
			type == WARNING ? "WARNING" :
			type == NOTE ? "NOTE" :
			type == CONT ? spacebuf : pc->curcmd,
			type == CONT ? " " : ":",
			buf);
		fflush(fp);
	}

"fp" being a global variable that is set to pc->tmpfile.
I suppose you can say, "works as expected", but it surely isn't as
I would expect.  How about a nice "standard_error" wrapper that
hides and restores that "fp" global variable thingy while invoking
__error()?  I can do it myself, but I really do not think it
advisable for crash client code to fiddle with what seems to me
to be internal state.

Thanks! - Bruce




More information about the Crash-utility mailing list