Path: utzoo!mnetor!uunet!husc6!mailrus!nrl-cmf!ames!pacbell!att-ih!ihnp4!inuxc!iuvax!bsu-cs!dhesi
From: dhesi@bsu-cs.UUCP (Rahul Dhesi)
Newsgroups: comp.lang.c
Subject: Re: huge problem
Message-ID: <2447@bsu-cs.UUCP>
Date: 23 Mar 88 14:33:42 GMT
References: <12575@brl-adm.ARPA>
Reply-To: dhesi@bsu-cs.UUCP (Rahul Dhesi)
Organization: CS Dept, Ball St U, Muncie, Indiana
Lines: 41

In article <12575@brl-adm.ARPA> PEPRBV%CFAAMP.BITNET@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