Re: [flint-devel] use of long in the FLINT API

[Michael A. <mab...@go...>]

On Thu, Jan 15, 2009 at 5:15 PM, Bill Hart <goo...@go...> wrote:

Hi Bill,

> It's ok to keep the discussion on list, but you are also welcome to
> take it offline.

I only meant to discuss the details of potentially meeting up at UW to
work on this. All the technical discussion should happen on list.

> You are welcome to check out FLINT and start modifying files if you
> want. One complication is that modifications for the FLINT 1.1 series
> need to be made to trunk *and* the flint-1.1 branch. There is no way
> to merge the changes to both automatically as the two directories
> differ. Note that there are more files in the trunk than the flint-1.1
> branch, but all files that appear in flint-1.1 also appear in trunk.

Ok, it seems like I should be working on the development version then
and if we get that to work we can always back port the relevant
changes. This allows for more flexibility and won't impact the stable
branch.

> I am the only person committing code at present and I am likely to
> spend time only in the files F_zmod_poly.c/h, F_zmod_poly-test.c and
> packed_vec.c/h (which only exist in trunk) for the next couple of
> days. Otherwise you are welcome to edit the other files as you wish.
> When it comes to modifying the files I am currently working on I'll do
> a commit so you can work on them.

Sure. As mentioned in the other mail my time for the next 10 or so
days is booked.

> I will enable write access to the flint-svn via your sourceforge
> username in a few moments. But can I ask that you tell me which files
> you're modifying two or three at a time so I can complain if
> necessary. :-)

Thanks, will do.

> You will also need to replace long with something. I don't know what
> to call it. slong will probably have to do, though it is very close to
> a rude Australian swear word,

Not only Australian :)

But I am wondering if using something closer to a C99 unsigned long
and signed long type might make the nature of ulong and "slong" more
clear. But I think this will cause confusion with the underlying gmp
types. I need to think about this more. Either way, signed and
unsignled long types should be consistent in naming convention if
possible. But in the end I can certainly live with

 ulong
 slong

> i.e. FLINT should use ulong instead of
> unsigned long and slong instead of long throughout. Finding where
> pointers are assigned to a ulong will be difficult to find. Looking
> for all occurrences of **, fmpz_t and ****alloc*** (e.g.
> flint_heap_alloc, malloc, flint_stack_alloc, flint_stack_alloc_small,
> flint_stack_alloc_bytes, etc) should get many of them.

Ok. There is a new valgrind tool called exp-ptrcheck that catches the
use of 32 bit pointers when interacting with 64 bit pointers. It
doesn't run on anything but Linux and I can't see a way yet to make
long on 64 bit platforms 32 bit without impacting all the other things
FLINT uses. There is no LLP Linux box AFAIK, so maybe using purify in
Windows might lead some assistance. In the end it might have to be
good old fashioned debugging :)

> Bill.

Cheers,

Michael