Sender:	vheyndri AT rug DOT ac DOT be
Message-Id:	<354435B1.7EA8@rug.ac.be>
Date:	Mon, 27 Apr 1998 09:37:21 +0200
From:	Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
Mime-Version:	1.0
To:	Nate Eldredge <nate AT cartsys DOT com>
Cc:	djgpp-workers AT delorie DOT com
Subject:	Re: Far string/mem functions
References:	<19980427032245 DOT AAC5484 AT ppp100 DOT cartsys DOT com>

Nate Eldredge wrote:
> >short sel = _dos_ds ();
> >printf ("%04X", sel);
> >
> >Try to guess what this prints when sel > 0x8000 (which it can never
> >compare to BTW, see the problem?).
> 
> I can see this as an argument for selectors being `unsigned short' vs.
> `short', but not `unsigned short' vs. `unsigned', which is the actual issue
> here. Am I missing something?

You are right I did not give a reason for that case:

Consider the example:

unsigned short sel = _dos_ds ();
short sel2 = sel;
unsigned sel3 = sel2;

Because there isn't anything to prevent the user from casting the
selector value to differently sized/signed types (as the user may assume
internal knowledge of selector layout), an ``unsigned'' eventually can
get the wrong value, possibly resulting in similar problems as stated
first. 
Whenever a user sees the prototype of _my_cs () then he would assume
that a selector is an ``unsigned'' and use that type himself to
represent selector values.
In the above example it's nearly obvious why it would fail, but through
a function call mechanism this can easily go undetected.
Whenever a selector would be ``unsigned short'' you just cannot assign
any other value to it than a value which is valid as a selector.
The advantage of using ``unsigned short'' is that the compiler makes
sure to reset the upper 16 bits in a register whenever needed, wherever
you would need to do that yourself if it were a plain ``unsigned''.

> Nate Eldredge
> nate AT cartsys DOT com

-- 
 \ Vik /-_-_-_-_-_-_/
  \___/ Heyndrickx /
   \ /-_-_-_-_-_-_/  Knight in the Order of the Unsigned Types

- Raw text -