On Tue, 15 May 2018, Jed Brown wrote:
> > Your notation requires the following change
> >
> > PETSC_EXTERN void PETSC_STDCALL dmdavecgetarrayf901_(DM *da,Vec
> > *v,F90Array1d *a,PetscErrorCode *ierr PETSC_F90_2PTR_PROTO(ptrd))
> > PETSC_EXTERN PetscErrorCode
> > F90Array1dCreate(void*,MPI_Datatype,PetscInt,PetscInt,F90Array1d*
> > PETSC_F90_2PTR_PROTO_NOVAR);
> >
> > to:
> >
> > PETSC_EXTERN void PETSC_STDCALL dmdavecgetarrayf901_(DM *da,Vec
> > *v,F90Array1d a,PetscErrorCode *ierr PETSC_F90_2PTR_PROTO(ptrd))
> > PETSC_EXTERN PetscErrorCode
> > F90Array1dCreate(void*,MPI_Datatype,PetscInt,PetscInt,F90Array1d
> > PETSC_F90_2PTR_PROTO_NOVAR);
>
> Yes.
>
> > [this doesn't look right.]
>
> I don't know why not,
output argument without a explicit pointer in definition is weird for c - and
can result in future bugs [when this code is changed]
> but I don't care about this narrow bit of
> compiler-enforced type safety enough to push for the more intrusive fix.
I'm not sure I understand what extra type safety is obtained by 'F90Array1d*'
vs 'F90Array1d' usage
Or does 'typedef struct { void *ptr; } F90Array3d;' give the extra safety? I
could change this part of typedef.
>
> > So I guess 'pointer to address (void*)' is the correct notation - as
> > we pass these back to fortran calling routine wrt
> > dmdavecgetarrayf901_() and an output argument for F90Array1dCreate().
>
> It's actually just the pointer that we have. The thing it points to is
> of some type that is not known statically in F90Array1dCreate/Destroy.
Yes. we get something opaque - and we pass it down to fortran utility routine
or up to the calling fortran routine - unmodified.
My current patch is at balay/fix-F90Array__Destroy/maint
Satish
