From: Ethan M. <merritt@u.washington.edu> - 2004-07-16 16:35:31
|
I'm moving this to the mailing list, because I hate the format of Email sent via the SourceForge patch site. On Friday 16 July 2004 02:22 am, Harald Harders wrote: > Ethan Merritt wrote in the summary for patchset #992149 > > internal.c internal.h > ================= > 1) Define a new internal function f_sprintf(). This is > visible to the user as a new built-in function > sprintf("fmt",...), which is the first, and so far the > only, function in gnuplot that accepts string variables > as arguments. > I think this patch looks like a good thing, but I really > don't like the name `sprintf'. It really sounds like a c > programmer had no good idea how to call it. I was not clear enough. This *is* the C language sprintf routine [*]. The gnuplot code just collects the variables and the format and passes them along to the C library. The documentation will refer users to "man sprintf" or to any C language manual. > set xlabel string(" %d %d %d", 1,2,3) > > The sprintf (or string) command should really understand all > gnuplot formats (%t, %T, %l, %L, etc.). For me, part of the rationale for this work is that the gnuplot formats are limiting. If there is some particular format that you cannot produce using a C language printf() variant, then we can provide a separate routine for that. Or there could be a second formatting function that specifically uses only the non-C gnuplot format conversion specifiers. mystring = string("Format using %T %L etc", var1, var2) set title sprint("C Format with embedded %s", mystring) [*] Actually, it's snprintf() because otherwise there is little hope of preventing all buffer overflows. As I recall, there is an issue with some platforms not providing snprint(). My inclination is to say that string variables are not supported on such platforms. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |