huge problem

[Rahul Dhesi]

In article <12575 at brl-adm.ARPA> PEPRBV%CFAAMP.BITNET at MITVMA.MIT.EDU (Bob
Babcock) writes:
>   struct record huge *xx;
...
>   xx=(struct record huge *)ALLOCATE(3001L,...
>/* Turbo C claims that huge pointers are always normalized, yet...
>   More subtle is the problem with xx[2047].string which gets an offset of
>   FFEC: the string crosses a segment boundary, so any use is likely to
>   suffer from segment wrap around.
>   printf("xx[0] - %Fp, xx[2047] - %Fp,  xx[3000] - %Fp\n",
>      xx[0].string, xx[2047].string, xx[3000].string);

As I understand it, you are saying that the address xx[2047].string,
being a huge pointer, ought to be kept always normalized.

But this is not really necessary.  Normalization will occur when this
address is incremented, because the runtime routine to increment a huge
pointer will be called.  Thus code of the form

     while ((*a++ = *b++) != '\0')
	;

will work for huge pointers, because a++ and b++ will correctly cause
the segment value to be incremented when the offset wraps around.
Similarly, if you find the difference (b - a), the runtime routine to
subtract huge pointers ought to correctly return the number of elements
between a and b even if neither a nor b was stored in normalized form.

What really matters is whether dereferencing a pointer, and doing
arithmetic with it in accordance with the rules of C, work correctly.

The problem really lies in the Turbo C documentation, which says that
huge pointers are stored in normalized form.  It should say that huge
pointers are normalized when necessary to correctly handle offset
wrap-around.  By contrast, if you increment a far pointer, offset
wrap-around is not correctly handled.  So for a far pointer, you must
have the value normalized else pointer arithmetic won't work
correctly.  This is the critical difference between far and huge
pointers.
-- 
Rahul Dhesi         UUCP:  <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi