Xref: utzoo comp.std.c:970 comp.lang.c:17313
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!husc6!ogccse!blake!uw-beaver!uw-june!ka
From: ka@june.cs.washington.edu (Kenneth Almquist)
Newsgroups: comp.std.c,comp.lang.c
Subject: Re: realloc
Message-ID: <7732@june.cs.washington.edu>
Date: 31 Mar 89 05:53:53 GMT
References: <10170@bloom-beacon.MIT.EDU> <10032@ihlpb.ATT.COM> <9118@alice.UUCP>
Organization: U of Washington, Computer Science, Seattle
Lines: 23

ark@alice.UUCP (Andrew Koenig) writes (r. e. the ANSI realloc function):
> Of course, not all C implementations behave this way.  This
> leaves C programmers in a bind: rely on this behavior or not?  If
> not, how does one determine which behavior can be trusted?  If
> so, what does one do when one's code breaks on various machines?

Given that the ANSI standard hasn't even been officially released,
C programmers shouldn't rely on this behavior now.  Maybe five years
from now we will find that virtually everyone has ANSI conformant C
libraries and we can start taking advantage of the ANSI realloc routine.
Until then, it's less of a hassle to type in a few extra lines of code
rather than having your code break in mysterious ways when it is ported
to a non-ANSI system.  The ANSI realloc is different from the majority
of ANSI features, which will cause your program to fail to compile on a
non-ANSI system and can therefore be adopted more aggressively.

As for Andrew's question about what programmer's *can* rely on, the
answer is the current de facto standard, which consists of the
language as defined in the first edition of K&R plus some later
enhancements to the language.  Exactly what is included in this
de facto standard is a matter of opinion, which is one reason for
the ANSI standard.
				Kenneth Almquist