Re: exposing cairo context from gnuplot

[Ethan M. <merritt@u.washington.edu>]

On Thursday 10 September 2009, Allin Cottrell wrote:
> 
> "Back to basics".  The only sort of thing you can literally "pass
> to" gnuplot (as an executable program) is a string, as in the argv
> array or as part of a "set foo ..." statement.

That's not really true.  It is certainly the most portable thing,
but far from the only thing.  You can pass shared memory objects,
or loadable shared libraries/plugins, for example.  There is even an
existing patchset on the SourceForge tracker that implements
loadable shared objects so that you can have pluggable math functions.

> However, strings can be interpreted in various ways.  If we're
> really talking about passing a pre-allocated cairo context to
> gnuplot, the only way I can envisage of doing this would be saying
> something like
> 
> set cairo_t "0x818a400"
> 
> (to a hypothetical gnuplot "raw_cairo" terminal).
> 
> It seems this would offer (depending on one's black-hat skill
> level) a good way of crashing gnuplot or turning it into a
> rootkit; 

It's no different than plugins in Firefox or Gimp or xmms or
MSWord or name your favorite application.  If the plugin is malicious
then, yeah, it can cause problems.  But only at the level gnuplot itself
can already cause problems.  It doesn't magically gain additional 
capabilities or privilege levels.

> but I suppose that in the right hands it could do what
> Richard is (I think) talking about -- i.e. get gnuplot to write
> into an area of memory rather than a file.

Maybe I mis-understand the intended use. I thought the proposed application
was to draw into an existing widget that was being displayed on the screen,
much like the x11 terminal can draw into an existing x-window.  If it's on
the screen, then it has a publically visible identifier already that the 
display/window manager can use.  You would in principle only have to pass that
identifier, just like passing the ID of an X window (and in fact it might even
_be_ the identifier of an X window; I don't know how gtk widgets work exactly).

Be that as it may, at least on linux "writing into an area of memory rather
than a file" is a false dichotomy.  You can map a file into memory and 
access it by either mechanism.  Or at least that is my understanding.
I admit that I've never programmed using memory-mapped files. See, e.g.
http://www.ecst.csuchico.edu/~beej/guide/ipc/mmap.html
So that might indeed be one way to implement this.


	Ethan