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 Mime-Version: 1.0 To: Nate Eldredge Cc: djgpp-workers AT delorie DOT com Subject: Re: Far string/mem functions References: <19980427032245 DOT AAC5484 AT ppp100 DOT cartsys DOT com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk 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