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

[Bill H. <goo...@go...>]

2009/1/16 Michael Abshoff <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.

Any changes to trunk without changing flint-1.1 will not appear in
Sage until FLINT 2.0 is released.

The vast majority of files are identical between the two at this
moment in time (which diff can check for you). If you change one
version, you may as well change the other). Of the remaining files,
most of those appear only in trunk. There are a handful of files which
appear in trunk and flint-1.1 which differ, but these are small enough
in number to deal with separately at present.

>
>> 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 used ulong because it is what David uses in zn_poly. It is
convenient because it is short to type. I don't know what he uses for
long. Probably he uses long.

>
>> 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 :)

Yeah I don't have any easy answers here. The problem is, it is not
going to be enough to just make sure all the tests pass. The tests are
not designed to pick up problems with pointer arithmetic. Presumably
the compiler will complain though. If it doesn't, send a strongly
worded letter to the compiler writer.

I suppose the compiler may not have a problem with using a 32 bit
ulong for pointer arithmetic between 64 bit pointers though.This would
be a serious bug which would affect FLINT in real world use but would
not fail a single test. The only way to fix that would be to check
every occurrence of * in FLINT and every occurrence of every type
which is typedef'd to some blah * or blah **.  If that is the case,
you're screwed, and see you in a year or two, I'm off to the Bahamas.

I expect the problem will be casts, which no doubt the compiler will
be happy with regardless if they are correct. But casts should always
be of the form (ulong *), (mp_limb_t *), etc or (ulong), etc,
depending which way the cast is. So if you look for all occurrences of
(ulong), (mp_limb_t), (F_mpz_t) and *) and **) you should get
everything the compiler misses,

Bill.