Re: [Plplot-devel] [Plplot-general] Any way to get a list of available devices to a program?

[Alan W. I. <ir...@be...>]

On 2013-11-21 23:10-0000 Andrew Ross wrote:

> On Thursday 21 Nov 2013 12:50:43 Alan W. Irwin wrote:
>> To James and Andrew:
>>
>> I am switching this discussion to the plplot-devel mailing list for obvious
>> reasons.
>> On 2013-11-21 15:08-0000 James Tappin wrote:
>>> When a program using plplot is run without a device specified (or with an
>>> unknown device), the program produces a list of devices and prompts for a
>>> device.
>>>
>>> Is there any way to get that list to a program (e.g. to put them into a
>>> selector widget, or to find available print-like devices)? [Preferably to
>>> Fortran].
>>
>> @Andrew:
>> Could you take a critical look at the API of this function as
>> well as plgFileDevs (the equivalent of plgDevs which is restricted to
>> returning a list of file devices).  I am no API expert, but it
>> makes absolutely no sense to me that the first two arguments of
>> these functions have types of const char *** type.  Surely the type
>> should be char ** for returning an array of character strings?
>> Anyhow, we use a variant of char ** for the pllegend arguments
>> involving arrays of character strings which is why I spotted
>> this issue.  It appears to me the current API means that an extra &
>> and a special cast has to be used in the
>> call, see
>>
>> plgFileDevs( (const char ***) &plFramePtr->devDesc, (const char ***)
>> &plFramePtr->devName, &ndev );
>>
>> in plframe.c, for example.  Anyhow, if you decide to change the API of
>> plgFileDevs and plgDevs (with a lowercase renaming as suggested below
>> if you think these functions should be propagated to all our
>> languages), then it should be done now (to give us several weeks to
>> test the result) or delayed until after our next _stable_ release.
>
> Alan,
>
> If we were just passing in an array of character strings then char ** would be
> fine, but in this case we need to return these arrays of strings to the user
> and so we need to pass in a pointer to the array of character strings. So I
> think the API is appropriate given the current implementation.
>
> Of course, there are other ways of achieving the same thing and you could
> argue about whether the current implementation is "safe" since we return
> pointers direct to the internal dispatch table rather than copies and so a
> malicious user could overwrite plplot internal information.
>

Hi Andrew:

You normally have the advantage of me in C expertise, but from
argument by analogy I think I am correct in this case.  For example,
you could use your argument to say input strings should be char *, but
output strings should be char **.  But in PLplot they are const char *
on input (e.g., plmtex text argument), and char * (not char **) on
output (e.g., plgver).  Non-PLplot examples of this symmetry between
input and output string types are various C library string routines
such as strcpy.  Similarly, I believe arrays of characters strings
should have similar symmetry (except for const qualifiers) between
input and output types.  After all, we go to all sorts of contortions
with const to make sure we identify the text argument (with type of
"const char *const *") for pllegend as input only.  Which implies a
routine could write out an array of character strings via char **
arguments if const qualifiers were not so deployed.

If you are not convinced at the moment, I promise to try (eventually)
a simple test case of an outer routine which allocs an array of
character strings, e.g., (note x33c.c does something similar)

     char       *text[MAX_DEVICES];
     for ( k = 0; k < MAX_DEVICES; k++ )
       text[k] = (char *) malloc( MAX_LENGTH_DEVICE_NAME * sizeof ( char ) );

Then see if a called routine can fill that array via a char **
argument.  Of course, there are constraints where MAX_DEVICES has to
be large enough and MAX_LENGTH_DEVICE_NAME has to be large enough. 
But plgver also has similar constraints on choosing the size of the
string in the calling routine to be large enough to hold a version
string so I don't think that is a major issue.

I will shut up now since I prefer to put off that demonstration (if
you think it is necessary) until after 5.10.0 is out since right now I
should be concentrating on getting out the next two releases.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________