apparently the standard says that:
65535 bytes in an object (in a hosted environment only)

and given that an object is:
object
region of data storage in the execution environment, the contents of
which can represent
values

makes me think that this was not expressed well enough.

observe:
#include <stdio.h>
#include <stdlib.h>

int main(void)
{
  int a; /* object */
  int *ptr; /* an object */

/* now we create an object dynamically */
  ptr = malloc(sizeof *ptr * 100);
  if(!ptr) {
      perror("malloc");
      exit(EXIT_FAILURE);
  }

  free(ptr);

  return 0;

I can't find anything in the standard that suggests
an object created dynamically should be distinguished
from an object not created dynamically.

Which means this rule applies to both:
65535 bytes in an object (in a hosted environment only)

Let me know if there is anything in the standard
that would contradict this by providing references
to clauses in the 9899:1999 standard.

--
aegis

On 6 Feb 2005 11:53:55 -0800, "aegis" <ae...@mad.scientist.com> wrote
in comp.std.c:

If you want to argue or question the standard, I would suggest you
spend the $18.00 US to get a copy.  Otherwise you place yourself at a
serious disadvantage.

While this does appear in versions of the C standard from 1999 and
later, you have plopped this into your post without any context at
all.

So let's put it in context:

========
5.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]

   — 65535 bytes in an object (in a hosted environment only)
========

This is one among 22 different items in the list.

Note the wording "contains at least one instance".  Also note the
complete absence of any mention of storage duration in the requirement
for object size.

Why do you assume anyone reading and/or posting to this group needs to
be told the definition of an object?

Makes you think what was not expressed well enough?  The text you
quoted without context?

Nothing in the standard says that.  But the wording you omitted is
"contains", not "dynamically allocates".  The malloc(), calloc(), and
realloc() functions do not return pointers to objects, they return a
pointer to "allocated space".  The allocated space may be used to
store one or more objects, but is not in itself an object.

Find the wording in the definitions of the malloc(), calloc(), or
realloc() that forbids them to fail at any time, for any reason.  A
strictly conforming implementation can return a null pointer for all
calls to these functions.  Nothing in the standard prevents it.

The line above is a phrase, with no context, not a rule.

Let me know if you find anything in the C99 standard that requires the
memory allocation functions to ever return anything other than a null
pointer.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html

news:1107719635.865484.182840@o13g2000cwo.googlegroups.com...

On an implementation where size_t is 16 bits, malloc can hardly ever allocate
more than 65535 bytes at a time.
Note also that on any system, there is no guaranty of any sort that malloc() can
allocate anything at all.
As a consequence, there is no particular constraint on the minimum size an
implementation must be able to allocate dynamically.

Another question is the minimum maximum size an automatic object is allowed to
be.
This seems to be a much stringer constraint for real systems, tied to operating
system configuration for default stack size and such.

Chqrlie.

The space malloc allocates is indeed an "object," one that has
incomplete type (and indeterminate (r)value right after allocation)

-----
See C99, 7.20.3.3, The malloc function

2. Description
The malloc function allocates space for an object whose size ...[snip]
-----

Malloc returns a pointer to this "object" (address of first byte of the
object with incomplete reference type).  Since the object's value is of
incomplete type, we can use a pointer(lvalues), with a reference "type"
of our choice, to this "object (or a parts of it)" and impress this
"type" to the value represented in the object (when lvalue -> rvalue
occurs).

So malloc does indeed allocate an object, which can hold
representations for values, and a type(incomp).  We, the users of
malloc, take advantage of this incompleteness to impose our will on the
value of any representation bits/bytes that we happen to store or read
into this object.

[Calloc on the other hand, allocates several objects (part of an
array), where the overall array itself is also an object]

I wouldn't say that the object has incomplete type; I'd say that it
doesn't have a type at all.  (malloc() returns a void*, but the object
isn't of type void, since it has a well defined size.)  A type is
imposed on it when a value is assigned to it (or when it's accessed as
an array of unsigned char, but there's not much point in doing that
before it's initialized).

--
Keith Thompson (The_Other_Keith) ks...@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
We must do something.  This is something.  Therefore, we must do this.

snip

Yeah, it has "no" type, which is still incomplete.  I don't know
whether the standard differentiates between NO TYPE and INCOMPLETE
TYPE, but it sure sounds like they aren't mutually exclusive sets.

news:1107982871.391843.305070@o13g2000cwo.googlegroups.com...

3.14
#1 object
region of data storage in the execution environment, the contents of which
can represent values
#2 NOTE When referenced, an object may be interpreted as having a particular
type; see 6.3.2.1.

6.3.2.1
#1 When an object is said to have a particular type, the type is specified
by the lvalue used to designate the object.

Type is imposed on the typeless object through "access" , not
"storage." Say I use an lvalue implying a type of T1 (such as through a
pointer with reference type T1) to store a value into the object.  What
is actually stored in the object is the representation that matches the
value & access type.  Say later I use a different lvalue implying a
type of T2 (such as through a diff. pointer with reference type T2) to
access the value in the object.  This value will not necessarily be the
same as the one we first stored.  Why? Because values are not stored,
only representations are.  So the first access stores a representation
of the value interpreted from the first type/value.  The second access
reads back the representation and it is interpreted to a different
type/value (in reality, type is part of values (either lvalues or
(r)values), but it's shown as two different things here for
explanations purposes, neverthless, type/value is still different from
the representation within an object).

Values are not stored in objects (they are only temporary things that
have meaning when a type is used to infer the meaning of bit/byte
representation sitting in the object).

The object allocated by malloc never gains a type or a value.  It stays
typeless and acts as a resevoir for bit/byte representations.  We only
gain meaning through access (if we maintain consistency in types used
to access the object, then that's just as good as assuming the
underyling object has that type).

Yes.  Objects don't have types, it's only specified by lvalues used to
designate the object.

For objects like:" int i = 0; ," there is no problem because the
integer object has a permanent lvalue available(i), which always has a
type of int.

But for objects that don't have a permanent lvalue(name of the object
is usually a permanent lvalue), then we must take extra care to keep in
mind the nature of using lvalues to "impose" a type on the object
whenever we access it.

[...]

It sure sounds to me like they are.  I don't think the standard
*explicitly* distinguishes between "no type" and "incomplete type",
but it seems clear that an "incomplete type" is a type, and that "no
type" is not.

--
Keith Thompson (The_Other_Keith) ks...@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
We must do something.  This is something.  Therefore, we must do this.

On 9 Feb 2005 11:21:21 -0800, "Kenneth Bull" <kenneth.b...@gmail.com>
wrote in comp.std.c:

Yes, it must be an object under the C definition of the term 'object'.
It is a region of storage, and it can be used to store values.

Nevertheless, it has no type at all.

Look at paragraph 6 of 6.5, and the supplemental footnote 72.

"Allocated objects have no declared type".  They can only acquire an
effective type when assigned to via an lvalue of non-character type,
which cannot happen until after you receive the pointer from *alloc.

An object of an incomplete type can't exist.  An object with no type
can, specifically by being allocated.  In fact, you can't define an
object with no type, and you can't allocate one with a type.

The definition of calloc() does not say that the memory has type.  It
specifically states:  "The calloc function allocates space for an
array of nmemb objects, each of whose size is size."  It is still
allocated space and has no type until stored to as above.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html

In C99 objects have effective types as specified by 6.5p6.

i's object always has an effective type of int.

Which is what effective type is all about, along with issues like
alignment.

Lawrence

Not according to the standard. 6.2.5p1 says

"Types are partitioned into object types (types that fully describe
 objects), function types (types that describe functions), and incomplete
 types (types that describe objects but lack information needed to
 determine their sizes)."

Soan incomplete type IS a type. If you have no type you don't have a type
at all, not even an incomplete one. An incomplete type is a type with
specific properties, not something that is somehow less than a type.

They are.

Lawrence

Lawrence Kirby is right: what malloc returns a pointer to
(when it is non-null) is an object that is an array of
bytes with additional alignment properties that not all
byte arrays are guaranteed to have.  However, there is no
*type* impressed upon it until it is accessed, and then
the type is determined by the type used for the access.
The exact clarification of this is expected eventually
in response to an open DR.