Path: ...!feed.opticnetworks.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Lawrence D'Oliveiro Newsgroups: comp.lang.c Subject: Re: realloc() - frequency, conditions, or experiences about relocation? Date: Tue, 25 Jun 2024 07:02:39 -0000 (UTC) Organization: A noiseless patient Spider Lines: 26 Message-ID: References: <875xtyu0kk.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Tue, 25 Jun 2024 09:02:39 +0200 (CEST) Injection-Info: dont-email.me; posting-host="250b38e1e4730787d8a829a06e323428"; logging-data="1524803"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+SGjpL9StpPMC2kahBnJRU" User-Agent: Pan/0.158 (Avdiivka; ) Cancel-Lock: sha1:HwjaYzZ7Kvw+8pyEo3UIcnw3XRY= Bytes: 2344 On Mon, 24 Jun 2024 02:55:39 -0700, Keith Thompson wrote: > Lawrence D'Oliveiro writes: >> >> The usual way I use realloc is to maintain separate counts of the >> number of array elements I have allocated, and the number I am actually >> using. A realloc call is only needed when the latter hits the former. >> Every time I call realloc, I will extend by some minimum number of >> array elements (e.g. 128), roughly comparable to the sort of array size >> I typically end up with. >> >> And then when the structure is complete, I do a final realloc call to >> shrink it down so the size is actually that used. Is it safe to assume >> such a call will never fail? Hmm ... > > It's not safe to assume that a shrinking realloc call will never fail. > It's possible that it will never fail in any existing implementation, > but the standard makes no such guarantee. > > ... > > Having said all that, if realloc fails (indicated by returning a null > pointer), you still have the original pointer to the object. In other words, it’s safe to ignore any error from that last shrinking realloc? That’s good enough for me. ;)