Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!wuarchive!emory!hubcap!grimlok From: grimlok@hubcap.clemson.edu (Mike Percy) Newsgroups: comp.lang.c++ Subject: Re: Borland's C++ memory allocation problems Message-ID: <10344@hubcap.clemson.edu> Date: 5 Sep 90 16:38:27 GMT References: <59280@bbn.BBN.COM> Organization: Clemson University, Clemson, SC Lines: 105 syswerda@bbn.com (Gilbert Syswerda) writes: >I have been having some problems with memory allocation using Borland's C++. >The problems seem to reside with the way sizes of objects are computed. An >example follows: Sorry, the problems arise _mostly_ in the way you are breaking the rules. But there is one buggy thing in here. >//************************************************ >#include >class c { > public: > char a[65536]; Point 1 -- 65536 is long, in this case it should be unsigned as well. To do less will generate a warning (if -w is set). Decimal constants are of type int, so 32767 is largest. This decimal constant is being promoted to long. Had this been 65535, we could have said 65535u and been within the range, and no warnings would be required. The line should be at least char a[65536l]; if not char a[65536ul]; However, all this is beside the point since the largest structure TurboC++ can properly allocate is 65534 bytes. I haven't figured out why not 65535 as one might think, but I think it has to do with pee-hole optimazations which would not be do-able if you allowed 65535 byte structures. Point 2 -- p331 [Programmer's Guide] With respect to ANSI Standard section 3.3.3.4 "The type of integer required to hold the maximum size of an array." For a normal array, the type is unsigned int, and for huge arrays the type is signed long. > } >void main() { >c b; > printf ("Sizeof c: %ld\n", (long) (sizeof (c))); > printf ("Sizeof b: %ld\n", (long) (sizeof (b))); > printf ("Sizeof b.a: %ld\n", (long) (sizeof (b.a))); > } Point 3 -- p334 [Programmer's Guide] With respect to ANSI Standard section 4.1.1 "The type of the sizeof operator, size_t." The type size_t is unsigned int. Casting an unsigned int to a signed long is dubious, it should be to unsigned long (however, the cast should work correctly since the smaller type was unsigned, the larger type will be zero filled rather than sign extended). A note here is that the %ld should be %lu if you change the cast to (unsigned long). But why make the cast? sizeof will _never_ return anything over 65535! >**********OUTPUT************* >Sizeof c: 2 >Sizeof b: 2 >Sizeof b.a: 65536 Point 4 -- garbage in, garbage out. You asked the compiler to do things it can't do, but it tried, and got the "wrong" results. >Doing a new() on an instance of class c results in only 2 bytes being >allocated. I have tried using both the compact and huge memory models. new() takes an argument that evaluates to a size_t number of bytes. This can be no larger than 65535 [note: for reasons having to do with TC++ heap management, this is really 65524 bytes in small data memory models and 65512 in large data memory models]. >I am new to both C and C++, so perhaps there is a simple misunderstanding >on my part. Anyone have any suggestions? Are you also new to the Intel chip structure -- this is the main root of these problems. An understanding of the languages invloved helps. An understanding of the machine lets you vent your anger at Intel when you see all the stupidities that have to be built into Intel compilers. Oh, yeah. I promised a bug. I feel that the bugs are in the fact that 1) the compiler didn't complain ferociously about the allocation of 65536 bytes. On second thought 65536 == 0 (in 16 bytes), so maybe it didn't have a problem exceeding the max. But it should still complian, and loudly! A hint to everyone who has these sort of problems: always compile with the -w switch enabled (eliminating all warnings eliminates virtually all of these sorts of problems, since you are forced to look up the cause in the manual). Another hint is to learn to read the -S output, which, by the way, is very, very, useful and readable from TC++. A look at the assembly code produced can provide great insights sometimes. "I don't know about your brain, but mine is really...bossy." Mike Percy grimlok@hubcap.clemson.edu ISD, Clemson University mspercy@clemson.BITNET (803)656-3780 mspercy@clemson.clemson.edu