Sender: vheyndri AT rug DOT ac DOT be
Message-Id: <35405B17.4B55@rug.ac.be>
Date: Fri, 24 Apr 1998 11:27:51 +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: <19980424035042 DOT AAG8293 AT ppp125 DOT cartsys DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

Nate Eldredge wrote:
> At 10:50  4/21/1998 +0200, Vik Heyndrickx wrote:
> 
> >  offsets are 'long unsigned int' (the same type as size_t)
> 
> I just followed `movedata's example. I don't see a problem offhand with
> using `unsigned long' instead, though it seems a moot point since they're
> really the same thing. Maybe DJ or whoever wrote `movedata' can tell why
> they chose `unsigned'?

Obviously he doesn't want to ;-(

Since on DJGPP 'unsigned' and 'long unsigned int' are both types with
exactly the same semantics (they are both unsigned and both 4 bytes
wide), there won't ever be problems what-so-ever with converting values
from the one to the other type. That is completely true. However, I want
there to be made choice (once in a while offsets also turn out to be
'signed int' in header files, and there I do have very strong objections
against, supported by good arguments).
I don't think that there is disagreement that there should be only one
type which is used as ``offset into a hardware segment''. An argument to
support this is the fact that pointers to these types better be
assignable without a cast or a compiler warning.

So making a choice: the only qualified types are 'unsigned' and 'long
unsigned'.
In my experience, whenever a type closely relates to a hardware
dependent feature, the width is always specified explicitely, probably
because the width of 'unsigned' is less stricktly defined in ANSI C. The
consistency rule implies we should use 'long unsigned'.

> >The gain from using unsigned for the selector instead is so marginal and
> >the potential number problems that may arise relatively so large that
> >'short unsigned' is the best choice.
> 
> It makes assembly functions that take selector arguments much easier to
> write when all arguments are 4 bytes in size, and there is (as you mention)
> a small performance difference.

An ``short unsigned'' variable on the stack also takes 4 bytes on the
stack and it starts also on the same address (little endianess). If the
performance difference would be multiplied with the fortune of MS's
chairman measured it dimes, it would still be neglidgible. The number of
bytes that would be added to the code size is neglidgible as well.

> However, I can't think of any of the "potential number of problems" that
> would arise. Can you list some?

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?).

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