Few doubts (wrong behaviour or correct )

[Dik T. Winter]

>
> N1124 7.20.3.3 The malloc function
> ...
> void *malloc(size_t size);
> Description
> The malloc function allocates space for an object whose size is
> specified by size ...

7.20.3:
"The pointer returned if the allocation succeeds is suitably aligned
so that it may be assigned to a pointer to any type of object and
then used to access such an object or an array of such objects in
the space allocated..."
I love such inconsistencies. Yes, I should have looked a bit further.

 

[Keith Thompson]

7.20.3:
"The pointer returned if the allocation succeeds is suitably aligned
so that it may be assigned to a pointer to any type of object and
then used to access such an object or an array of such objects in
the space allocated..."
I love such inconsistencies. Yes, I should have looked a bit further.

What inconsistency are you referring to? You wrote above that:

Malloc is described as returning an object or an array of objects
of the type of the pointer the result is assigned to.

Where did you get that description? (malloc() doesn't return an
object or an array of objects; it returns a pointer value of type
void*.)

 

[Dik T. Winter]

>
> What inconsistency are you referring to? You wrote above that:
> Malloc is described as returning an object or an array of objects
> of the type of the pointer the result is assigned to.
> Where did you get that description? (malloc() doesn't return an
> object or an array of objects; it returns a pointer value of type
> void*.)

Well, I thought the description was a bit inconsistent. But that is just
my opinion.

 

[Dik T. Winter]

Some additional thoughts about this:

> Andrey:

> > >>> int arr[100];
> > >>> int (*parr)[5] = (int(*)[5]) &arr;
> > >>>
> > >>> (*parr)[5] = 42;

Note that if this would not be permitted,
int *qarr = (int *)&arr;
qarr[5] would also not be permitted.
the only difference is that parr is a pointer to array 5 of int, and qarr
is a pointer to int (which, when indexing, would be assumed to be an array 1
of int). So when indexing the actual *type* of the pointer is not relevant.

This does *not* destroy the possibility of bounds checking. When an object
is created, remember first address and size of the object and transfer that
to every pointer pointing into the object (or one past the object).

I see however one problem. Consider:
typedef struct {int p, q;} structure;
structure x;
is:
(&(x.p))[1]
correct? You would not like that, but it is nevertheless allowed
(arithmetic is still within the main object). Unless you consider that
x.p denotes a member object (of type int), and use that in the description
of valid indexing. But if you do that you get in problems with:
int a[5];
(&(a[3]))[1];
because now a[3] denotes an element object, and this indexing would also
not be allowed (the element object is also of type int).

The only solution (in my opinion) is to consider member objects (of structs
and unions) as true objects, while element objects are not so considered,
in the context of indexing.

 

[Keith Thompson]

Well, I thought the description was a bit inconsistent. But that is just
my opinion.

If the description you're referring to is the one that describes
malloc() as "returning an object or an array of objects of the type of
the pointer the result is assigned to", then yes, it's inconsistent --
because it's wrong. There is no such description in the standard (and
there shouldn't be one in any decent textbook).