On Sat, 3 Nov 2001, Uri Guttman wrote:
> >>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> DS> 2) A buffer object has the structure:
>
> DS> struct {
> DS> void *memory;
> DS> INTVAL size;
> DS> }
>
> some questions.
>
> i am declaring a BIGNUM struct which points to an array of BIGNUM_WORDs
> (longest native integers). do i have to declare it like that? or will
> the GC work with any pointer type and cast it for me?
The GC will cast appropriately.
> also since some platforms require alignment, will i be able to assure
> that buffer is BIGNUM_WORD aligned?
Good question. The buffer will have a guaranteed natural bast-case
alignment for the platform you're on. (We don't want to segfault because
we're misaligning an array of doubles or __int128s)
> finally, i need the size in BIGNUM_WORDs. so should i have both a byte
> size as you do and my own count of BIGNUM_WORDs?
Yep. Especially because the size is the total buffer size--if you're
using less, you'd want a separate length to note that.
> and since we are on this topic, how worried should i be about freeing or
> not? there will be times when the BIGNUM package will need to allocate
> BIGNUM temps and can then explicitly reuse or free them. should (some
> form of) free be called or should i let the memory leak for the GC to
> pick up later?
Just let it leak--the GC system will clean things up appropriately.
> there will also be needs for realloc type calls. will
> there be support for that?
Yup.
> what about allocating zeroed memory (i know
> bzero is easy to call) which make life simpler for BIGNUM?
Yup. Enough people will want it that it makes sense.
> BTW we have basic multiword BCD add subtract working. scaling and
> conversions are next.
Yay! Cool. The rest of the issues can be dealt with separately. (Sizes and
things will probably be something passed in at bignum construction time or
something like that)
Dan
