Tim,
You've missed the whole business of "handles" for objects in object.c.
The "pointers" that are converted by astP2I and astI2P are not in fact
genuine pointers, they are "ID"s for objects which are guaranteed to fit
into 4 bytes. These identifiers are generated by the astMakeId function is
object.c.
So it *should* all just work on 64 bit machines....
David
On Thu, 9 Sep 2004, Tim Jenness wrote:
> I've cnf_pval'ed CONVERT and tried it out on the AMD64 system.
> Unfortunately I get a segv inside ast (see later in email).
>
> Taking a look at ast:object.c astI2P and astP2I I'm not sure I understand
> exactly how this is meant to work on a 64bit system.
>
> It all seems to be based on a union:
>
> /* Define a union with an overlapping int and AstObject*. This is used
> to transfer an integer bit pattern into and out of a pointer
> variable used to store an Object identifier. This avoids any
> implementation dependent aspects of integer-to-pointer
> conversions. */
> typedef union IdUnion {
> AstObject *pointer;
> int integer;
> } IdUnion;
>
> and then astI2P does this:
>
> temp.pointer = zero_ptr;
> temp.integer = integer;
> return temp.pointer;
>
> and astP2I does this:
>
> temp.pointer = pointer;
> return temp.integer;
>
> I can't understand how this works since it seems that nowhere does the
> pointer to integer mapping get stored (cf cnfMem.c). The upper 32bits of
> the pointer are simply discarded. This entire chunk of
> code seems to achieve 3 things:
>
> 1. Get rid of warnings about casting a pointer to integer of different
> size
>
> 2. Assumes that the lower 32 bits contain all the relevant pointer
> information.
>
> 3. Keeps all the pointer->integer conversions in a single place.
>
> Point #3 is the good news. #2 only works if you are forcing your
> compiler to use 32bit pointers on 64bit compilers.
>
> I think that this can all be made to work if
>
> 1. astMalloc internally uses cnfMalloc
> [although the addition of an extra chunk of memory in the malloc
> leading to an offset pointer will cause problems]
>
> 2. astI2P is changed to use cnfCptr
>
> 3. astP2I is changed to use cnfFptr
>
> but I don't know what the policy on this is given that ast is going
> through hoops so as not to be dependent on anything else except slalib.
> [my argument to this would be to spend a bit of effort on officially
> GPL'ing CNF and then placing rpms/debian packages whatever in prominent
> locations so that it no longer seems to be some esoteric starlink
> software but a generally useful library for fortran programmers.
> Submitting it for inclusion into debian would be an excellent
> start]
>
> Alternatively, cnfMem.c has to be reimplemented. I think it could be done
> a lot more straightforwardly than CNF simply by storing the C pointers
> into an array and return the index as the integer.
>
> Tim
>
>
> #0 DSSToStore (this=0x754bf0, store=0x76b940, method=0x2a96f1030e
> "astRead", class=0x2a96f1016d "FitsChan") at string2.h:982
> #1 0x0000002a96de08bf in FitsToStore (this=0x754bf0, encoding=2,
> method=0x2a96f1030e "astRead", class=0x2a96f1016d "FitsChan")
> at fitschan.c:8342
> #2 0x0000002a96ded75f in Read (this_channel=0x2) at fitschan.c:19155
> #3 0x0000002a96dc6aeb in astRead_ (this=0x754bf0) at channel.c:4847
> #4 0x0000002a96dd24e1 in ast_read_ (THIS=0x7fbfffc754,
> STATUS=0x7fbfffe36c) at fchannel.c:420
> #5 0x00000000004380c6 in cof_wcsim_ (fc=0x7fbfffcb3c, indf=0x7fbfffcf24,
> nencod=0x7fbfffd3b4, encods=0x7fbfffda00, status=0x7fbfffe36c,
> __g77_length_encods=6662835) at cof_wcsim.f:259
> #6 0x0000000000436c31 in cof_ftwcs_ (funit=0x7fbfffcf9c,
> indf=0x7fbfffcf24, nencod=0x7fbfffd3b4, encods=0x7fbfffda00,
> file=0x7fbfffd900,
> wcsatt=0xffffffff, status=0x7fbfffe36c, __g77_length_encods=255,
> __g77_length_file=255, __g77_length_wcsatt=255) at cof_ftwcs.f:198
> #7 0x000000000041efe1 in cof_f2ndf_ (filnam=0x7fbfffd900,
> ndf=0x7fbfffd3a8, loghdr=0x7fbfffd3a4, fdl=0x7fbfffd41c,
> fmtcnv=0x7fbfffd3cc,
> profit=0x7fbfffd3c4, proxti=0x0, contnr=0x7fbfffd3bc,
> nencod=0x7fbfffd3b4, encods=0x7fbfffda00, wcsatt=0x7fbfffd420,
> status=0x7fbfffe36c, __g77_length_filnam=255, __g77_length_encods=255,
> __g77_length_wcsatt=255) at cof_f2ndf.f:1191
> #8 0x000000000040f067 in fits2ndf_ (status=0x7fbfffe36c) at
> fits2ndf.f:1411
> #9 0x000000000040c3aa in convert_mon_ (status=0x7fbfffe36c) at
> convert_mon.f:78
> #10 0x000000000040c19b in dtask_applic_ (context=0x754bf0, actcode=0x20,
> aname=0x0, actptr=0x22, seq=0x7fbfffe10c, value=0x7fbfffe170,
> schedtime=0x7fbfffe110, request=0x7fbfffe114, status=0x7fbfffe36c,
> __g77_length_aname=0, __g77_length_value=444) at dtask_applic.f:66
> #11 0x0000002a979c7b78 in dtask_obeydcl_ (dtask_applic_=0x40c110
> <dtask_applic_>, name=0x0, value=0x7fbfffe170, status=0x7fbfffe36c,
> __g77_length_name=0, __g77_length_value=444) at dts_obeydcl.f:106
> #12 0x0000002a979c6503 in dtask_dcltask_ (devinit=0x7fbfffe170,
> dtask_applic_=0x40c110 <dtask_applic_>, status=0x7fbfffe36c)
> at dts_dcltask.f:98
> #13 0x000000000040c098 in MAIN__ () at dtask_main.f:116
> #14 0x0000000000524d82 in main ()
>
>
> --
> Tim Jenness
> JAC software
> http://www.jach.hawaii.edu/~timj
>
|