Hi Arjen:

On 2014-09-10 07:54-0000 Arjen Markus wrote:

> Hi Alan,

> By using the fixed number 4 you make a classical mistake: the kind
number is not related to the number of bytes that a value of the given
kind and type occupies in memory. For instance: years ago (before
Fortran 90 compilers were common enough) I used a NEC computer that
had two different types of single-precision reals, one native, fast
but not portable, and one conforming to IEEE. They both occupied 4
bytes of memory. The kind system has been explicitly defined to
distinguish such formats.

Thanks for letting me know about that issue.  I am sure you are
correct, but the Fortran tutorials and compiler documentation I
have read over the years were blind to it.  So I was as well.
I conclude from this that kind = 4 for integers is usually
correct, but not always.

> You do have a point though - the types on the Fortran side should match the 
> types on the C side. Therefore I suggest using:
>
> use, intrinsic :: iso_c_binding, only: c_int32_t
>
> integer, parameter :: plint = c_int32_t
>

Your argument implies the current

integer, parameter :: plunicode  = 4

in bindings/f95/plflt.inc.in is not 100 per cent reliable.

The C equivalent is essentially typedefed by

typedef uint32_t   PLUNICODE;

So in sum my guess is
bindings/f95/plflt.inc.in should include these lines:

use, intrinsic :: iso_c_binding, only: c_int32_t
integer, parameter :: plint = c_int32_t

use, intrinsic :: iso_c_binding, only: c_uint32_t
integer, parameter :: plunicode = c_uint32_t

(But nothing concerning a plbool definition since we are leaving
logical types as is). Do you think the above would work?  In other
words, am I correctly understanding your "use" syntax to import exact
C types into Fortran?

> [...] Since we do not rely on a magical match between C's booleans
and Fortran's logical, we can simply use the default kind, implicitly
or explicitly, for our Fortran logical data.

OK.  That means we should leave the logical types just like they are
except for checking the logical type covers all the PLBOOL C argument
equivalents that have been systematically replacing PLINT C arguments
where appropriate over the years.  And I guess we should check the
plunicode coverage versus PLUNICODE C argument as well.

I am tied up with a timeephem mini-project at the moment that will take the
rest of the week at least.  Therefore, once you decide the right thing
to do with bindings/f95/plflt.inc.in, please commit that change. Note,
your plint value will be ignored temporarily, but the plunicode value
is used in both our Fortran bindings and examples so any changes you
make to that definition would be immediately tested.

You could also make all the additional changes to our Fortran bindings
and examples to convert all instances of integer to
integer(kind=plint). But I see no point in you doing all that editing
by hand, when sed facilities are available to me to do most of it
automatically.  Therefore, I volunteer for that task (but after my
timeephem mini-project is done).

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
__________________________

------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Plplot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Reply via email to