Re: PETSc-FUN3D Code

["Matthew Knepley" <knepley@xxxxxxxxx>]

On 10/20/07, Satish Balay <balay@xxxxxxxxxxx> wrote:
> Matt,
>
> The primary problem here is:
>
> we have size_t in prototypes - for eg:
>
> PetscErrorCode PetscMemzero(void *a,size_t n);
>
> So, when this routine is called from fortran - what datatype should
> user-fortran-code use? Currently there is no equivalent for size_t.
> [integer and size_t don't match on 64bit machines]
>
> My proposal is to have PetscSizeT [atleast on the fortran side - that
> is set properly - simlar to PetscFortranAddr].
>
> And we normally have types match on both fortran & c - so should we
> use it for C-side aswell?

I would rather run the logic backwards. In my opinion, typedefing size_t in
C is the correct solution and leaves you with sane looking code. Fortran is
the problem here. So define a type size_t in Fortran as well.

    Matt

> PetscErrorCode PetscMemzero(void *a,PetscSizeT n);
>
> BTW: This requires configure to set PETSC_SIZEOF_SIZE_T. [I've added
> in this check]. But as you say - if size_t is not in system include
> files - configure typedefs it. But I'm not sure if PETSC_SIZEOF_SIZE_T
> test will compile in this case. [typdefs set by configure don't appear
> to be used in checkSizeof() test.
>
> Satish
>
>
> On Sat, 20 Oct 2007, Matthew Knepley wrote:
>
> > I actually like the autoconf solution. If the type is not found (size_t)
> > then just typedef it as something.
> >
> >    Matt
> >
> > On 10/20/07, Barry Smith <bsmith@xxxxxxxxxxx> wrote:
> > >
> > >   Satish,
> > >
> > >    I don't know; there are pros and cons to the two
> > > approaches.
> > >
> > >    Why not PetscSize_T? I admit both look stupid, but the
> > > _ at least matches the standard C style.
> > >
> > >   Any comments from the community?
> > >
> > >   Barry
> > >
> > >
> > >
> > >     I would like to keep size_t as the argument
> > >
> > > On Sat, 20 Oct 2007, Satish Balay wrote:
> > >
> > > > On Fri, 19 Oct 2007, Dinesh Kaushik wrote:
> > > >
> > > > > > > Perhaps need a PetscSizeT or some new datatype for this purpose that
> > > > > > > gets set correct for both C & fortran side..
> > > >
> > > > Barry,
> > > >
> > > > Is it ok to do this change? The prototypes of the following functions
> > > > will need to be changed to use PetscSizeT instead of size_t;
> > > >
> > > > [alternative is to use size_t on the C side - but PetscSizeT on the
> > > > fortran side - but this is inconsistant]
> > > >
> > > > thanks,
> > > > Satish
> > > >
> > > > -------------------
> > > > PetscBagCreate
> > > > PetscFileRetrieve
> > > > PetscGetArchType
> > > > PetscGetDate
> > > > PetscGetDisplay
> > > > PetscGetFullPath
> > > > PetscGetHomeDirectory
> > > > PetscGetHostName
> > > > PetscGetProgramName
> > > > PetscGetRelativePath
> > > > PetscGetTmp
> > > > PetscGetUserName
> > > > PetscGetWorkingDirectory
> > > > PetscLs
> > > > PetscMalloc
> > > > PetscMalloc2
> > > > PetscMalloc3
> > > > PetscMalloc4
> > > > PetscMalloc5
> > > > PetscMalloc6
> > > > PetscMalloc7
> > > > PetscMemcmp
> > > > PetscMemcpy
> > > > PetscMemmove
> > > > PetscMemzero
> > > > PetscOptionsGetenv
> > > > PetscOptionsGetString
> > > > PetscOptionsString
> > > > PetscSetMalloc
> > > > PetscSNPrintf
> > > > PetscStrlen
> > > > PetscStrncat
> > > > PetscStrncmp
> > > > PetscStrncpy
> > > > PetscStrreplace
> > > > PetscSynchronizedFGets
> > > > PetscVSNPrintf
> > > >
> > > >
> > >
> > >
> >
> >
> >
>
>


-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which
their experiments lead.
-- Norbert Wiener