On Wed, 30 Apr 2008, Tim Jenness wrote:
> Daft question, but why doesn't cnfCref initialise the buffer with spaces?
All just a guess, but I'd say that's because this behaviour is the same as
Fortran. Strings are not initialised by default.
> I ask because I get tons of valgrind warnings from any C interface that does
>
> F77_CREATE_CHARACTER( X, N );
> F77_CALL(xxxx)( CHARACTER_ARG(X) TRAIL_ARG(X) );
> F77_IMPORT_CHARACTER( X, N, x );
>
> presumably because cnfCref initialises the first character to \0 but does
> not initialise anything else. And since it's explicitly a fortran string
> buffer shouldn't it initialise the whole string with ' '.
>
> The warning is triggered in cnfImprt since it starts at the end of the string
> and works its way to the front.
I'd say the error here is one of two possibilities.
That the called subroutine isn't initialising the character string and it
should. If that's a returned string then it should be initialised (unless
there's a STATUS that you haven't shown, which goes back to a conversation
on this list a while back about what actions you should take before
checking the global status).
Or you could also say that since you're relying on having an initialised
return from the call it's your job to initialise the string (or deal with
the bad status return explicitly).
(Not going to offer up the thought that since the routine returns an
uninitialised string that's exactly what should be imported into C, so the
current behaviour is correct.)
> cnfCref explicitly states that it does not initialise but I assume that is
> historical to save time.
Could be just masking other issues if you do that globally. Personally,
after our last chat about this area, I'd look at the Fortran and see if
it's appropriate to initialise the string.
Peter.
|