Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!uunet!dev8o.mdcbbs.com!campbell
From: campbell@dev8o.mdcbbs.com (Tim Campbell)
Newsgroups: comp.lang.c
Subject: Re: Problems allocating 300k data structure using Turbo C
Message-ID: <1991Mar19.131107.1@dev8o.mdcbbs.com>
Date: 19 Mar 91 13:11:07 GMT
References: <1991Mar15.230133.16073@lynx.CS.ORST.EDU>
Distribution: usa
Organization: McDonnell Douglas M&E, Cypress CA
Lines: 57
Nntp-Posting-Host: dev8o
Nntp-Posting-User: campbell

In article <1991Mar15.230133.16073@lynx.CS.ORST.EDU>, kemps@prism.CS.ORST.EDU (Scott Micheal Kemp) writes:
> Machine: IBM 386
> Compiler: Turbo C++
> Problem: Need to make an array larger than 64k.
>  
> Specifically, I need to create a dynamic array of a 10 byte
> structure which will need over 300k.

A friend of mine just went through this problem.  Here's what we know.
Your problem exists *only* because you are using a segmented memory
environment.  Specifically this problem was identified in Borland's Turbo
C - I imagine that the problem is a carry-over into C++.  We also tried
it using a Microsoft compiler and had the same problem - I suspect you'll
find most C compilers on a PC (segment memory) will have this problem.
The address (offset) of the *beginning* of any element in a structure, must
be within 64k bytes of the beginning of the base pointer to the structure.
Basically, the compiler assumes that all elements of a structure are located
in the same memory segment as the base of the structure (they share segment
addresses).  It does not matter what memory model you use, it does not matter
if you allocate the memory static or dynamic - you will have this problem
no matter what (we can find no way to fix it other than writing "voodoo code".

Here's an example.

	struct {
	    char array_1[65534];
	    char array_2[5];
	    char array_3[10];
	} stuff;

The machine will have no problem accessing stuff.array_1 - this element is
completely within 64k of the base address of "stuff".
The machine will have no problem accessing stuff.array_2 - although this
element does cross the 64k barrier - the fact is, it *begins* before the
64k barrier (the beginning is all that matters - if it can find out where
the data begins, it will find everything).
The machine *WILL* have a problem with stuff.array_3.  This is because the 
base of array_3 is more than 65535 bytes from the start of "stuff".  Basically
you'll have a "wrap around" effect.  It will attempt to locate array_3 only
five bytes from the base of "stuff".

We maintain that this is a "bug" - Borland seems to maintain that their
compiler simply doesn't support this "feature".  So I guess if you consider
proper compilation and execution of code to be a "feature" you might be
inclined to agree with Borland.  Other compilers (those not dependent on
segmented memory) don't seem to have this problem.  And of course I don't
beleive the language spec limits structures or arrays (aggregates) to 64k.

	-Tim

  ---------------------------------------------------------------------------
	  In real life:  Tim Campbell - Electronic Data Systems Corp.
     Usenet:  campbell@dev8.mdcbbs.com   @ McDonnell Douglas M&E - Cypress, CA
       also:  tcampbel@einstein.eds.com  @ EDS - Troy, MI
 CompuServe:  71631,654
 P.S.  If anyone asks, just remember, you never saw any of this -- in fact, I 
       wasn't even here.