realloc

David Levine davidl at intelob.intel.com
Thu Mar 30 00:18:34 AEST 1989


In article <10170 at bloom-beacon.MIT.EDU> scs at adam.pika.mit.edu (Steve Summit) writes:
>                                  ... It is an apparently well-
>  kept secret that realloc is supposed to behave gracefully at
>  a slightly special-cased boundary point: when handed a NULL
>  pointer and a nonzero size, it acts essentially as a malloc.

The System V Interface Definition (which, despite its many flaws, IS
an established standard, unlike the pANS which is still only a "draft
proposed standard") doesn't require this behavior.  The documentation
for UNIX System V, BSD 4.3, and ULTRIX doesn't mention any special
behavior for reallocing a null pointer; in fact, they all say that
attempting to realloc a pointer that was not returned by malloc,
calloc, or realloc will have unexpected results.  (Yes, malloc can
return a null pointer... I think that they meant a pointer returned by
a SUCCESSFUL call to malloc, calloc, or realloc.)

This means that you are depending on an undocumented feature.  You
shouldn't be surprised when it breaks.

The behavior you describe IS required by the pANS.  You can depend on
this behavior in any ANSI-Standard implementation, but if you expect
it of any System V, BSD, or ULTRIX implementation (and quite possibly
many others), you're expecting something that isn't promised by the
manufacturer.  This, of course, is the whole point of standards.
Unfortunately, there are as yet no ANSI-Standard implementations,
since there is no approved Standard yet.

            David D. Levine                BBBBBBBBB  IIII IIII NNN  NNNN TM
        Senior Technical Writer            BBBB  BBBB iiii iiii NNNN NNNN
                                           BBBBBBBBB  IIII IIII NNNNNNNNN
UUCP: ...[!uunet]!tektronix!biin!davidl    BBBB  BBBB IIII IIII NNNN NNNN
MX-Internet: <davidl at intelob.intel.com>    BBBBBBBBB  IIII IIII NNNN  NNN
ARPA: <@iwarp.intel.com:davidl at intelob.intel.com>



More information about the Comp.std.c mailing list