Hi,

I'm new to Fortran and require some help understanding the capabilities
of Fortran when it comes to calling C/C++ functions.  Specifically I
would  like to make use of C's memory manipulation functions, in
partucular realloc, memcpy and memmove.

I have writen some F95 code which calls a C function, the function
allocated some mem and populates an array.  However the memory is not
availabe to me back in teh Fortran calling function.  Any attemp to
access the data result in a seg fault.

Any advice on how to do this would be welcome!

Cheers,

Jon

Calling C from Fortran is often discussed here. Can you post a small
code example illustrating your problem and specify the compilers and
operating system?

May I ask why you do not allocate the memory in the Fortran code,
perhaps using ALLOCATABLE arrays?

"jon.gill@metoffice.gov.uk" wrote:
> I'm new to Fortran and require some help understanding the capabilities
> of Fortran when it comes to calling C/C++ functions.  Specifically I
> would  like to make use of C's memory manipulation functions, in
> partucular realloc, memcpy and memmove.

If that is all you wish to do, why bother with C?  It is trivial to
write ones own 'realloc' routine in F95.  Use F90 pointers, the ALLOCATE
and DEALLOCATE statements.  The only 'hard' part is deciding how to move
the data when multi-dimensional arrays are reallocated.  (E.g., Does one
treat the existing data as a submatrix?  Or move it as a contiguous
chunk - like C's realloc would?)

For moving blocks of memory around, without regard to the rank of the
array, try the BLAS SCOPY/DCOPY/CCOPY/ZCOPY routines.

> I have writen some F95 code which calls a C function, the function
> allocated some mem and populates an array.  However the memory is not
> availabe to me back in teh Fortran calling function.  Any attemp to
> access the data result in a seg fault.

No doubt.  If one really really needs to use non-Standard allocation
technique (e.g., for mmaping files), there is no way in F95 to build
up a F95 POINTER from an externally provided address.  And a F95
POINTER maintains quite a bit more information than a simple address.
However there are a couple of ways of doing it, but details depend on
which compiler(s) you are using.  ("Cray pointers" are a huge help - if your
compiler supports them.)

Eventually F2003 will be implemented and become widespread.  Then
the new C Interop features will make this a bit easier.  But I don't
know of any compiler which implements F2003 yet, so don't hold your
breath.

Walt
-...-
Walt Spector
(w6ws at earthlink dot net)

Walter Spector wrote:
> "jon.gill@metoffice.gov.uk" wrote:
> > I'm new to Fortran and require some help understanding the
capabilities
> > of Fortran when it comes to calling C/C++ functions.  Specifically
I
> > would  like to make use of C's memory manipulation functions, in
> > partucular realloc, memcpy and memmove.
>
> If that is all you wish to do, why bother with C?  It is trivial to
> write ones own 'realloc' routine in F95.  Use F90 pointers, the
ALLOCATE
> and DEALLOCATE statements.  The only 'hard' part is deciding how to
move
> the data when multi-dimensional arrays are reallocated.  (E.g., Does
one
> treat the existing data as a submatrix?  Or move it as a contiguous
> chunk - like C's realloc would?)
>
> For moving blocks of memory around, without regard to the rank of the
> array, try the BLAS SCOPY/DCOPY/CCOPY/ZCOPY routines.
>
> > I have writen some F95 code which calls a C function, the function
> > allocated some mem and populates an array.  However the memory is
not
> > availabe to me back in teh Fortran calling function.  Any attemp to
> > access the data result in a seg fault.
>
> No doubt.  If one really really needs to use non-Standard allocation
> technique (e.g., for mmaping files), there is no way in F95 to build
> up a F95 POINTER from an externally provided address.  And a F95
> POINTER maintains quite a bit more information than a simple address.
> However there are a couple of ways of doing it, but details depend on
> which compiler(s) you are using.  ("Cray pointers" are a huge help -
if your
> compiler supports them.)
>
> Eventually F2003 will be implemented and become widespread.  Then
> the new C Interop features will make this a bit easier.  But I don't
> know of any compiler which implements F2003 yet, so don't hold your
> breath.

On this subject, is the F2k3 C_PTR just another name for a cray pointer
in most cases (same functionality, different syntax)?

> 
> Walt
> -...-
> Walt Spector
> (w6ws at earthlink dot net)

In article <1111690418.840398.58250@o13g2000cwo.googlegroups.com>,
 gary.l.scott@lmco.com wrote:

> On this subject, is the F2k3 C_PTR just another name for a cray pointer
> in most cases (same functionality, different syntax)?

I wouldn't call the functionality of the F2k3 C_PTR quite the same as 
that of Cray pointers, but there certainly are significant overlaps - 
significant enough that I personally consider the C_PTR feature to be a 
good candidate for a standardized replacement for Cray pointers. If 
anything, I'd say that C_PTR has more functionality than Cray pointers 
(and a syntax that is immeasurably better - in my own very personal 
opinion, the syntax of Cray pointers is a counter-intuitive 
abomination). The C_PTR feature wasn't originally explicitly designed as 
a Cray pointer replacement, but it became evident to me (and some 
others) fairly early on that it could also serve that purpose, even in 
code that had nothing to do with C per se.

-- 
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

Richard E Maine wrote:
> 
> In article <1111690418.840398.58250@o13g2000cwo.googlegroups.com>,
>  gary.l.scott@lmco.com wrote:
> 
> > On this subject, is the F2k3 C_PTR just another name for a cray pointer
> > in most cases (same functionality, different syntax)?
> 
> .... The C_PTR feature wasn't originally explicitly designed as
> a Cray pointer replacement, but it became evident to me (and some
> others) fairly early on that it could also serve that purpose, even in
> code that had nothing to do with C per se.

I agree - to a large extent.

However Cray Pointers, as traditionally implemented by Cray at least,
also infer that no aliasing is occuring.  This means that the array
accesses are optimizable in the same manner that normal non-pointer
arrays are. So there can be performance implications compared with
F90 POINTERs and, I presume, F2003 C_PTRs.

Guess we need a RESTRICT attribute...

Walt
-...-
Walt Spector
(w6ws at earthlink dot net)