Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
From: Nate Eldredge <nate AT cartsys DOT com>
Subject: Re: Far string/mem functions
Cc: djgpp-workers AT delorie DOT com
Date: Sun, 26 Apr 1998 20:22:52 -0700
Message-ID: <19980427032245.AAC5484@ppp100.cartsys.com>
Precedence: bulk

At 11:27  4/24/1998 +0200, Vik Heyndrickx wrote:
>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'.

Okay, that makes sense. There is also the tradition on many systems that
`unsigned long' is the same size as a pointer (the 64-bit Alpha, for
instance, uses 32-bit ints, but 64-bit longs). I have no objection to
switching to `unsigned long' (or `long unsigned', for that matter).

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

Upon checking this, I see you are right. That was my major objection, but it
was groundless.

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

True.

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

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?

Nate Eldredge
nate AT cartsys DOT com