Re: nsaddr_t - why is it an int32_t?

[Lloyd Wood <l.wood@eim.surrey.ac.uk>]

On Thu, 27 Jan 2000, Sean Murphy wrote:

> I think nsaddr_t should be a u_int32_t - I've spent most of the afternoon
> looking for a problem that wouldn't have arisen if nsaddr_t was a
> u_int32_t - essentially, it was a test for mcast in the rsvp/ns code that
> worked by comparing the node addr with 1 << McastShift (addr >=
> 1<<mcastshift) - if the comparison is done using u_int32_t's everything is
> ok, but if int32_t's are used, then the result is not the desired result.
> It's probably better to use a bitwise and based test which would return
> the correct result in any case but I still think it more natural for
> nsaddr_t to be u_int32_t's.
> 
> Is there a reason why nsaddr_t's should be int32_t's? Are there situations
> in which negative node numbers are used?

In a similar vein, I'd like to ask about negative time.

clock() returns a double, but simulations start halfway at 0; as far
as I can tell you can't start simulations at an arbitrary negative
time and run them forwards to execute events scheduled in negative
time, by setting the start time with e.g.

$ns run from -500.0

(or, more usefully, $ns run from 20 if you want to skip creating some
 traffic in the first part of your simulation but can't be bothered to
 comment it out; $ns run would be the same as $ns run from 0. Handy.)

Might be useful to have more control over clock precision for some
long simulations.

[This came up a while back when I was convincing Tom that a
 bit of satellite geometry code needed finetuning to cover for
 the possibility, since the possibility was beyond our control...]

L.

is wondering why the commented-out line in ns-lib.tcl:
Simulator instproc run {} {
        #$self compute-routes

<L.Wood@surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>