🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.std.c
Article #1199

Re: calloc()

#1199
From: Steve Clamage
Date: Mon, 14 Sep 1992 17:54
28 lines
1627 bytes
darcy@druid.uucp (D'Arcy J.M. Cain) writes:

>steve@taumet.com (Steve Clamage) writes:
>>That said, suppose we have a system where int and size_t are 16 bits,
>>but it is possible to allocate an object bigger than 64K.  A

>But isn't size_t guaranteed to be big enough to specify any object?  It
>is stated in a kind of roundabout way in the standard (you have to follow
>up sizeof) but I don't think there is any doubt that if an object can be
>larger than 64K then size_t must reflect this.

size_t is the type returned by the sizeof operator.  I believe you
must be able to apply sizeof to any object you can declare.  Suppose
ints and size_t are each 16 bits, and the compiler rejects any attempt
to declare an object greater than 64K:
	int big    [32767];	/* OK */
	int bigger [32769];	/* ERROR: too big */
This could be a conforming implementation.

Now suppose that the implementor wants to allow access to extra
memory when it is available, and allows calls like
	calloc(1024, 100)	/* 100K allocation */
for example.  I don't think this violates any rules.  You can't
use sizeof to find the size of a dynamically allocated region.
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Technical Details
Message-ID: <1992Sep14.175431.10043@taumet.com>
Path: arc1-ca.pugleaf.net!sparky!uunet!taumet!steve
References: <14455@goanna.cs.rmit.oz.au> <1992Sep10.180542.1009@taumet.com> <1992Sep13.142340.24107@druid.uucp>

Show Full Headers
Complete Article Headers
Newsgroups: comp.std.c
Path: arc1-ca.pugleaf.net!sparky!uunet!taumet!steve
From: steve@taumet.com (Steve Clamage)
Subject: Re: calloc()
Message-ID: <1992Sep14.175431.10043@taumet.com>
Organization: TauMetric Corporation
References: <14455@goanna.cs.rmit.oz.au> <1992Sep10.180542.1009@taumet.com> <1992Sep13.142340.24107@druid.uucp>
Date: Mon, 14 Sep 1992 17:54:31 GMT
Lines: 28