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

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

On Thu, Jan 15, 2009 at 6:56 PM, Bill Hart <goo...@go...> wrote:
> 2009/1/16 Michael Abshoff <mab...@go...>:

<SNIP>

>> 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.

Yes, but I see porting patches to FLINT 1.1 once they have worked out
in the FLINT 2.0 trunk.

> 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.

Ok, good to know.

>> 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.

That sounds like it will be another library to revisit. Let's hope he
abstracted out all the types, but I haven't looked.

>> 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.

Well, this was meant to test is there is still any long pointer
lurking around somewhere. The compiler should pick all of them up, but
we will see.

> 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,

I guess learning about all the gory internals of FLINT can't be a bad thing :)

> Bill.

Cheers,

Michael

> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> flint-devel mailing list
> fli...@li...
> https://lists.sourceforge.net/lists/listinfo/flint-devel
>