🚀 go-pugleaf

In article <Snews.960727.045510.chris.317@keris.demon.co.uk>
           chris@keris.demon.co.uk "Chris Croughton" writes:

> In article <838411052snz@dsl.co.uk>
>            bhk@dsl.co.uk "Brian {Hamilton Kelly}" wrote:
 
 <snip on snip of good stuff>

> >    I've counted 429 lines in the sources which mention int32, and
> >that's without looking at the OS/2 specific files!
> 
> ...
> Since the code works at the moment, how about replacing all 'int32'
> declarations with 'uint32', and then setting that one to the proper
> 'int32'?  There might still be other bugs caused by this, but doing that
> shouldn't make anything worse than it is at present.

That was my initial thought, and one which will involve a fair
bit on editing (not to mention checking and testing!).

My second thought (and I must say I didn't scan the source too
closely) was that it might be simpler to redefine the ttl
member of struct rr as a simple 'long'.  With any luck (and a
slight tailwind:) the effects should be limited to domain.c and
domhdr.c.  At the very least I'd guess that there are fewer than
429 accesses to 'rr.ttl' vars.

Of course, the simplest(!) fix would be to recode all instances 
of the type that Brian originally cited where ttl expressions
are checked for < 0, ie.

  if (test_rrp->ttl > 0L
  && (test_rrp->ttl -= elapsed) <= 0L)
          test_rrp->ttl = 0L;
to eg.

  if (test_rrp->ttl != 0L)
      test_rrp->ttl = (test_rrp->ttl > elapsed) ? 
                       test_rrp->ttl - elapsed  : 0L;

though I'm sure someone could improve on the efficiency.

In saying all this, I've never come across a -ve TTL in my
domain.txt here.  Yet.
-- 
Pete