Re: realloc() implicit free() ?

Robert Gamble wrote:

On Sat, 21 May 2005 16:38:51 +0200, Michael Mair wrote:


CBFalconer wrote:

"S.Tobias" wrote:


CBFalconer <cbfalconer@xxxxxxxxx> wrote earlier:


In my nmalloc implementation for DJGPP I have chosen to treat a zero
block size as a request for one byte, and let the alignment mechanisms
raise it as they will.


I'm not criticizing this, there're good reasons to do it like that, but
the Standard does not require the allocated object to have alignment
more than its size, right?  Subsequent `malloc(1)'-s could return ptrs
that differ by 1 byte, right?  (I'm asking because the Std is a bit
unclear there, IMHO.)


No, that can't happen.  Any non NULL return from malloc/calloc/realloc
must be suitably aligned for any object whatsoever.

Can you provide chapter and verse, please? 


7.20.3p1 sentence 2:

"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 (until the space is explicitly deallocated)."


    Taken in isolation, this sentence says that

	struct s { char c[30000]; } x = { 0 };
	struct s *p = malloc(1);  /* assume success */
	*p = x;

should work: The allocation has succeeded, the returned value
is therefore suitably aligned for any type (`struct s' in
particular), the value can be assigned to any type of pointer
(including `struct s*'), and can then be used to access an
object of that type.  All the preconditions of the sentence
are met -- and yet, the access is obviously not permitted.

    What this means is that snipping a sentence from the rest
of the Standard can distort its meaning.  Elsewhere in the
Standard we can learn that `*p = x' produces undefined behavior,
so no conforming program can access a `struct s' through the
value returned by this particular malloc().  It follows that no
conforming program can actually encounter any alignment
problem by trying to access a `struct s' through this pointer;
the access itself is forbidden.  Under the "as if" rule, if
nothing else, I believe malloc(1) can perfectly well return a
value that is not `struct s'-aligned because no conforming
program can ever detect the non-alignment.

    However, the quoted sentence still places some restrictions
on what malloc(1) could return.  For example,

	void *p1 = malloc(1);  /* assume success */
	double *dp = p1;
	void *p2 = dp;
	assert (p2 == p1);

That is, converting the pointer to `double*' and back again
must not change its value.  On machines where pointers to
different types have different representations, malloc(1) is
constrained to return values that can be converted to and from
any data pointer type without damage -- but as long as the
conversion is guaranteed to succeed, I don't think the value
need actually suffice for any data type that won't fit in the
allocated space.

--
Eric Sosman
esosman@xxxxxxxxxxxxxxxxxxx

.

Relevant Pages

  • Re: "free space" with declared type (alignment discussion)
    ... >>a function pointer member, a struct pointer member, and maybe a few ... > It doesn't put any extra constraint on alignment beyond this. ... > To assess actual alignment constraints, a structure might be used to figure how ...
    (comp.lang.c)
  • Re: N1298 - try/finally for C
    ... Do you mean that "struct throwInfo" should be optional? ... that exception handling would be supported only on implementations ... If the standard mandates an integer as throw argument, ... should be an integer wide enough to encode a pointer if necessary. ...
    (comp.std.c)
  • Re: Alignment
    ... mallocreturn addresses that satisfy whatever alignment ... Ain't it good enough to say that malloc returns an address good for storing any data type? ... Perhaps the Standard could have avoided talking about ... alignment if it instead imposed an "assignable to any pointer" ...
    (comp.lang.c)
  • Re: ptr conversions and values
    ... it's not obvious that every object pointer points to a byte. ... types shall have the same representation. ... and having the same representation and alignment ... >> to accept any struct pointer via stdarg interface. ...
    (comp.std.c)
  • Re: [JW] alignment problem for structures
    ... It's not a *requirement* that any particular shorts must be located at those ... One thing that's awkward about my implementation is that one plus a pointer ... >> model is not sufficient to describe all possible types of alignment ... > constrained than the standard actually requires. ...
    (comp.std.c)