Tim,
I've just got round to this.
On Wed, 3 Nov 2004, Tim Jenness wrote:
> ccdpack/main/ndf.c has a fortran/C pointer problem
>
> /* Call the routine which does the calculations. */
> F77_CALL(ccd1_fra)( CHARACTER_ARG(type), INTEGER_ARG(&ndf1->nel),
> (F77_POINTER_TYPE) &ndf1->data,
> INTEGER_ARG(&nfrac), DOUBLE_ARG(afracs),
> LOGICAL_ARG(&bad), DOUBLE_ARG(work),
> DOUBLE_ARG(avals), INTEGER_ARG(status)
> TRAIL_ARG(type) );
>
> at line 2616. I've committed a possible fix:
>
> * Call the routine which does the calculations. */
> F77_CALL(ccd1_fra)( CHARACTER_ARG(type), INTEGER_ARG(&ndf1->nel),
> (F77_POINTER_TYPE) cnfFptr( &ndf1->data ),
> INTEGER_ARG(&nfrac), DOUBLE_ARG(afracs),
> LOGICAL_ARG(&bad), DOUBLE_ARG(work),
> DOUBLE_ARG(avals), INTEGER_ARG(status)
> TRAIL_ARG(type) );
>
> but I haven't tested it (I'm assuming that ndf1->data refers to a mapped
> data array so the pointer is registered already with CNF).
Your assumption is right, but I'm not convinced the fix is - the
blame for this lies entirely with me for writing it in the first
place in a way which is at least confused, and probably wrong.
I've committed changes which use CNF in a more standard way here and
in a couple of other places in the same file, which I hope (and believe)
are correct. I've tested on 32 bits (RH9) but not on 64 bits.
I'm not sure how you spotted this in the first place (compiler warning?),
but if you could do whatever you did then and check it still looks
kosher I'd be grateful.
Mark
--
Mark Taylor Starlink Programmer Physics, Bristol University, UK
[log in to unmask] +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/
|