From: Ethan M. <merritt@u.washington.edu> - 2003-10-24 19:24:30
|
On Friday 24 October 2003 12:06, Daniel J Sebald wrote: > I've looked at the code in term.c regarding opening the file. > It looks like the terminal initialization is very safely done with > appropriate checks of a variable "term_initialised". I'm > wondering if the actual "fopen()" can't be held off until the > function "term_start_plot()". Apparently you are not the first one to think so. The comment in term_init (term.c line 406) reads: /* this is nasty - we cannot just term_set_output(outstr) * since term_set_output will first free outstr and we * end up with an invalid pointer. I think I would * prefer to defer opening output file until first plot. */ > and in graph3d.c at the start of the "do_plot3d()" routine is > > term_start_plot(); > [Why there isn't a term_init() there also, I don't know.] The first thing term_start_plot() does is call term_init(). So it isn't really necessary in graphics.c at all. > So, it would mean keeping track of the output file name using > a character pointer and realloc() and keeping track of the > binary/ascii file type. In term_start_plot(), check if the file > name is non-NULL, and if so open the file and free() > the memory for the name and set the pointer back to NULL. > > Does it seem like that would work? It could be made to work, but I see several problems. =20 The first is that if the output file is illegal it makes far more sense to get that error message immediately from the 'set output' command. If you defer trying to open the file until later, the error message becomes decoupled from the command that caused it. Also, remember that some terminal types can put multiple plots into a single file, while others cannot. I would have to delve into the code to see if moving the file open to=20 term_start_plot() would trip over that difference or not. --=20 Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Box 357742 University of Washington, Seattle, WA 98195 |