lfpinit() signed or unsigned?

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 
> esr at thyrsus.com said:
> > It doesn't matter.  All those calculations are casted to within an inch of
> > their lives. :-) 
> 
> Would it help to have another signed type?

The short answer is "no".  The longer answer:

The macros that are the API for the abstract data type are constructed
to be indifferent to whether the underlying concrete 64-bit type is
signed or unsigned.  If I were willing to commit either way I could
throw away several of them in favor of bare arithmetic operations.

I've chosen not to do that because the reality is that the code sometimes
wants to treat the abstract type as signed and sometimes as unsigned. So no,
it wouldn't help to have another signed type unless we were willing to do
a really invasive refactor on all the usage sites.

That is a prospect that makes me even more nervous than the dodgy casts and
type punning we're using now. At least the present organization can in
principle be tested by checking a bunch of invariants and properties of
the abstract type - in practice we may not have noticed all the predicates
we *should* check, but in principle we could get there.

If we changed all those usage sites I think the proof problem would become
a lot more difficult.  That's why, as nervous as the present code makes me,
I haven't tried to abolish the abstract data type it implements.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Please consider contributing to my Patreon page at https://www.patreon.com/esr
so I can keep the invisible wheels of the Internet turning. Give generously -
the civilization you save might be your own.