Xref: utzoo comp.std.c:952 comp.lang.c:17283 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!mit-eddie!uw-beaver!blake!ogccse!littlei!omepd!davidl From: davidl@intelob.intel.com (David Levine) Newsgroups: comp.std.c,comp.lang.c Subject: Re: realloc Message-ID: Date: 29 Mar 89 14:18:34 GMT References: <10170@bloom-beacon.MIT.EDU> Sender: news@omepd.UUCP Organization: BiiN Information Systems, Hillsboro, Oregon Lines: 33 In-reply-to: scs@adam.pika.mit.edu's message of 29 Mar 89 02:07:46 GMT In article <10170@bloom-beacon.MIT.EDU> scs@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: BBBBBBBBB IIII IIII NNNN NNN ARPA: <@iwarp.intel.com:davidl@intelob.intel.com>