From: Stephan Wilms <Stephan DOT Wilms AT CWA DOT de>
Newsgroups: comp.os.msdos.djgpp,comp.lang.c
Subject: Re: x/0, and a problem with realloc
Date: Fri, 30 Jan 1998 13:47:17 +0100
Organization: CWA GmbH
Lines: 30
Message-ID: <34D1CBD5.79E5@CWA.de>
References: <Pine DOT LNX DOT 3 DOT 96 DOT 980130215217 DOT 25140A-100000 AT central DOT caverock DOT co DOT nz>
Reply-To: Stephan DOT Wilms AT CWA DOT de
NNTP-Posting-Host: morgoth.cwa.de
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk

Eric Gillespie wrote:
> 
> I am a beginner programmer, and have been writing a file lister program.
> In this program, I allocated an array (calloc) and later on, realloc'ed it.
> When later checking the array, contrary to what my documentation says, a
> large hunk of my array had been wiped!  Does (should?) realloc behave the
> same under gcc as under Turbo C?
[SNIP]
>    Excerpt from Turbo C Bible (C) 1989 The Waite Group p 138
> 
>      Description: ... The memory block of altered size may [possibly] not
>                   be located at the same address, but the contents of the
>                   new block (up to its old size) are guaranteed to be
>                   unchanged.

Hi Eric Gillespie,

You refer to Turbo-C and DJGPP in particular, but the behaviour quoted
above is actually guarantied by ANSI-C. So, if you've got a compiler
that claims to be ANSI-C compatible, it must behave in this way.

> For this reason, I cannot understand why my code is getting blitzed.

[MEGA SNIP]

Please read the reply by Rainer Temme, who has spotted a coding error
in your source code.

Stephan
(initiator of the campaign against grumpiness in c.l.c)