From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,5c666efe108c1065 X-Google-Attributes: gidfac41,public X-Google-Thread: 109fba,5c666efe108c1065 X-Google-Attributes: gid109fba,public X-Google-Thread: 1014db,5c666efe108c1065 X-Google-Attributes: gid1014db,public X-Google-Thread: 1108a1,5c666efe108c1065 X-Google-Attributes: gid1108a1,public X-Google-Thread: 114917,5c666efe108c1065 X-Google-Attributes: gid114917,public X-Google-Thread: 114809,5c666efe108c1065 X-Google-Attributes: gid114809,public X-Google-Thread: 103376,5c666efe108c1065 X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,bc16c150b1957917 X-Google-Attributes: gidf43e6,public From: Chris Engebretson Subject: Re: Help you C++ Debuggers! Date: 1997/01/21 Message-ID: <32E5982A.3A7@sdsumus.sdstate.edu>#1/1 X-Deja-AN: 211488267 references: <32DEF075.41C6@bme.ri.ccf.org> <1997Jan20.144447.5581@news> content-type: text/plain; charset=us-ascii organization: As little as possible. mime-version: 1.0 reply-to: e8ag@sdsumus.sdstate.edu newsgroups: comp.lang.c,comp.lang.c++,comp.lang.asm.x86,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng x-mailer: Mozilla 3.0 (Win95; I) Date: 1997-01-21T00:00:00+00:00 List-Id: David Emery wrote: > >C does not support objects greater than 32767 bytes portably. > > Huh? Where in the C Language Definition is this specified? Tanmoy's correct. The size of an object is measured by the sizeof operator, which yields type size_t. More specifically, the Standard defines size_t (in ) to be a constant of unsigned integral type. Beyond that, the Standard also says: 2.2.4.1 Translation limits The implementation shall be able to translate and execute at least one program that contains at least one instance of every one of the following limits: [ snip unrelated limits ] * 32767 bytes in an object (in a hosted environment only) Seems pretty clear-cut to me. :-) It's helpful not to confuse pointers with objects; if I write char *ptr; ptr = malloc (8 * 1024 * 1024); I now have a pointer to an eight-megabyte region of allocated memory (provided, of course, that the allocation succeeds.) But despite what noted fools such as Herbert Schildt would have you believe, sizeof (ptr) == sizeof (char*), not (8 * 1024 * 1024). In other words, the size of a pointer is just that: the size of the pointer. It isn't the size of the region it points to. On the other hand, if you write char array[8 * 1024 * 1024]; you may very well run into problems, depending on the definition of size_t. Since declaring an automatic array of this size is completely ridiculous, though, I'd hardly consider this a fault. > Given the > limitations of Intel 80x86 16-bit architectures, I could understand > this being a possible limitation of poor PC C compilers. But I can't > see this as being a shortcoming of the C -language-. > As a programming language, C has lots of shortcomings, but this isn't > one (any) of them... Whether or not it's a shortcoming is a matter of opinion, but the fact remains that it's a part of the language. PS: Also note Tanmoy's phrase "portably"; 32767 bytes is all that the Standard guarantees, although you may be able to "get away with" a larger object. But again, in cases where an object larger than this is needed, it only makes sense to use an allocated region, as opposed to an automatic/static object. And at least within the realm of c.l.c, this "limitation" should be respected. Regards, -- Chris Engebretson -- e8ag@sdsumus.sdstate.edu Linux -- The choice of a GNU generation! I'm at home, so what my employer thinks is irrelevant.