[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]

RERE>>Signed/Unsigned confu



Reply to:   RERE>>Signed/Unsigned confusio
ok,  I'll take a look at the code today to make sure that this stuff is handled
correctly.
  The purpose of those two unsigneds is as low and high water marks (well,
sorta - current ones) on the primarray as an efficiency measure in the
calculation of the domain.  Since the primarray can only have unsigned indices,
it seemed correct to use unsigned markers.  The really correct answer is just
to be sure that they aren't paid attention to if tally==0.

--------------------------------------
Date: 9/14/90
To: heh 
From: vlad!mark
Received: by xanadu.com; 14 Sep 90 01:14:45
Received: from vlad.UUCP by xanadu  (4.1/SMI-4.0.2) id AA01543; Fri, 14 Sep 90
01:08:41 PDT
Received: by vlad. (4.0/SMI-4.0)
	id AA16238; Fri, 14 Sep 90 00:59:36 PDT
Date: Fri, 14 Sep 90 00:59:36 PDT
From: vlad!mark (Mark S. Miller)
Message-Id: <9009140759.AA16238@vlad.>
To: heh@xxxxxxxxxxx
Cc: michael@xxxxxxxxxxx, xtech@xxxxxxxxxxx
In-Reply-To: heh's message of 13 Sep 90 16:36:08 <9009132331.AA26997@xanadu >
Subject: RE>Signed/Unsigned confusio

   Date: 13 Sep 90 16:36:08
   From: heh <xanadu!xanadu.com!heh>

	   Reply to:   RE>Signed/Unsigned confusion
   right.  oops.
     I can't look at the code right now, but I think the correct answer is to
   return either 0 (lastElemBefore) or the primarray count - 1
(firstElemAfter). 
   This should make the low water mark > the high water mark, which would mean
   that the table is empty.

But if the table is empty, then "primarray count - 1" will still be
negative (and hence a type violation).  Does Michael's suggestion
work?

   Date: Thu, 13 Sep 90 20:47:30 PDT
   From: xanadu!michael (Michael McClary)

   BLAST()

   Which is the generic answer to "How do I return an exception when every
   member of the set of possible return values is a valid non-exceptional
   result?"

   Magic numbers are for people who don't have an exception-handler.

I suspect not, as (on inspection of the code) the real question is:
what values should the instance variables take on?  (Although I like
Michael's answer in general for the kind of thing I originally thought
I was asking about.)  Any reason we don't use IntegerVars?

Btw, the *only* place either of the offending methods are called is
from "ActualIntegerTable::wipe.IntegerVar" (to mix language
notations).