Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #386054 > unrolled thread

realloc() - frequency, conditions, or experiences about relocation?

Back to article view | Back to comp.lang.c

Contents

  realloc() - frequency, conditions, or experiences about relocation? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-17 08:08 +0200
    Re: realloc() - frequency, conditions, or experiences about relocation? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-06-16 23:34 -0700
    Re: realloc() - frequency, conditions, or experiences about relocation? Ben Bacarisse <ben@bsb.me.uk> - 2024-06-17 10:18 +0100
      Re: realloc() - frequency, conditions, or experiences about relocation? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-17 10:31 +0100
        Re: realloc() - frequency, conditions, or experiences about relocation? Ben Bacarisse <ben@bsb.me.uk> - 2024-06-17 10:55 +0100
          Re: realloc() - frequency, conditions, or experiences about relocation? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-17 13:45 +0100
            Re: realloc() - frequency, conditions, or experiences about relocation? Ben Bacarisse <ben@bsb.me.uk> - 2024-06-17 15:33 +0100
              Re: realloc() - frequency, conditions, or experiences about relocation? Anton Shepelev <anton.txt@g{oogle}mail.com> - 2024-06-17 18:10 +0300
                Re: realloc() - frequency, conditions, or experiences about relocation? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-18 00:09 -0700
                  Re: realloc() - frequency, conditions, or experiences about relocation? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-18 11:19 +0100
                    Re: realloc() - frequency, conditions, or experiences about relocation? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-18 11:46 +0100
                      Re: realloc() - frequency, conditions, or experiences about relocation? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-29 00:14 +0000
                        Re: realloc() - frequency, conditions, or experiences about relocation? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-07-02 10:18 +0100
                          Re: realloc() - frequency, conditions, or experiences about relocation? Ben Bacarisse <ben@bsb.me.uk> - 2024-07-02 16:39 +0100
                          Re: realloc() - frequency, conditions, or experiences about relocation? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-07-03 23:48 +0000
                    Re: realloc() - frequency, conditions, or experiences about relocation? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-24 09:32 -0700
                      Re: realloc() - frequency, conditions, or experiences about relocation? David Brown <david.brown@hesbynett.no> - 2024-06-24 19:19 +0200
                  Indefinite pronouns [was:Re: realloc() - frequency, conditions, or experiences about relocation?] Anton Shepelev <anton.txt@gmail.moc> - 2024-06-20 02:51 +0300
                    Re: Indefinite pronouns vallor <vallor@cultnix.org> - 2024-06-20 00:34 +0000
                      Re: Indefinite pronouns David Brown <david.brown@hesbynett.no> - 2024-06-21 12:59 +0200
                        Re: Indefinite pronouns Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-21 10:31 -0700
                    Re: Indefinite pronouns [was:Re: realloc() - frequency, conditions, or experiences about relocation?] gazelle@shell.xmission.com (Kenny McCormack) - 2024-06-20 12:10 +0000
                      Re: Indefinite pronouns [was: Re: <something technical>] Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-20 15:04 +0200
                    Re: Indefinite pronouns [was:Re: realloc() - frequency, conditions, or experiences about relocation?] Cri-Cri <cri@cri.cri.invalid> - 2024-06-21 00:55 +0000
                    Re: Indefinite pronouns [was:Re: realloc() - frequency, conditions, or experiences about relocation?] Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-20 23:23 -0700
              Re: realloc() - frequency, conditions, or experiences about relocation? Richard Harnden <richard.nospam@gmail.invalid> - 2024-06-17 16:15 +0100
                Re: realloc() - frequency, conditions, or experiences about relocation? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-06-17 13:05 -0700
              Re: realloc() - frequency, conditions, or experiences about relocation? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-17 16:36 +0100
            Re: realloc() - frequency, conditions, or experiences about relocation? Anton Shepelev <anton.txt@g{oogle}mail.com> - 2024-06-17 18:02 +0300
              Re: realloc() - frequency, conditions, or experiences about relocation? "David Jones" <dajhawk18xx@@nowhere.com> - 2024-06-18 17:59 +0000
              Re: realloc() - frequency, conditions, or experiences about relocation? davidd02@tpg.com.au (David Duffy) - 2024-06-19 06:48 +0000
                Re: realloc() - frequency, conditions, or experiences about relocation? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-19 10:12 +0100
                  Re: realloc() - frequency, conditions, or experiences about relocation? Ben Bacarisse <ben@bsb.me.uk> - 2024-06-19 16:36 +0100
                    Re: realloc() - frequency, conditions, or experiences about relocation? David Brown <david.brown@hesbynett.no> - 2024-06-19 19:41 +0200
                      Re: realloc() - frequency, conditions, or experiences about relocation? Ben Bacarisse <ben@bsb.me.uk> - 2024-06-19 22:24 +0100
                        Re: realloc() - frequency, conditions, or experiences about relocation? David Brown <david.brown@hesbynett.no> - 2024-06-20 13:22 +0200
                  Re: realloc() - frequency, conditions, or experiences about relocation? Anton Shepelev <anton.txt@gmail.moc> - 2024-06-20 01:53 +0300
                    Re: realloc() - frequency, conditions, or experiences about relocation? Anton Shepelev <anton.txt@g{oogle}mail.com> - 2024-07-08 19:34 +0300
                Re: realloc() - frequency, conditions, or experiences about relocation? Anton Shepelev <anton.txt@g{oogle}mail.com> - 2024-06-19 15:20 +0300
              Re: realloc() - frequency, conditions, or experiences about relocation? Rich Ulrich <rich.ulrich@comcast.net> - 2024-07-02 00:51 -0400
                Re: realloc() - frequency, conditions, or experiences about relocation? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-01 22:10 -0700
                  Re: realloc() - frequency, conditions, or experiences about relocation? Rich Ulrich <rich.ulrich@comcast.net> - 2024-07-02 11:45 -0400
                    Re: realloc() - frequency, conditions, or experiences about relocation? Anton Shepelev <anton.txt@g{oogle}mail.com> - 2024-07-08 20:01 +0300
                      Re: realloc() - frequency, conditions, or experiences about relocation? Rich Ulrich <rich.ulrich@comcast.net> - 2024-07-21 19:40 -0400
                        Re: realloc() - frequency, conditions, or experiences about relocation? Anton Shepelev <anton.txt@g{oogle}mail.com> - 2024-07-23 16:47 +0300
                Re: realloc() - frequency, conditions, or experiences about relocation? Paul <nospam@needed.invalid> - 2024-07-02 03:02 -0400
                  Re: realloc() - frequency, conditions, or experiences about relocation? Rich Ulrich <rich.ulrich@comcast.net> - 2024-07-02 11:52 -0400
                    Re: realloc() - frequency, conditions, or experiences about relocation? Rich Ulrich <rich.ulrich@comcast.net> - 2024-07-02 11:58 -0400
                      Re: realloc() - frequency, conditions, or experiences about relocation? Paul <nospam@needed.invalid> - 2024-07-02 15:09 -0400
                        Re: realloc() - frequency, conditions, or experiences about relocation? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-02 16:54 -0400
                        Re: realloc() - frequency, conditions, or experiences about relocation? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-02 16:58 -0400
            Re: realloc() - frequency, conditions, or experiences about relocation? scott@slp53.sl.home (Scott Lurndal) - 2024-06-17 16:58 +0000
              Re: realloc() - frequency, conditions, or experiences about relocation? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-06-17 13:12 -0700
            Re: realloc() - frequency, conditions, or experiences about relocation? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-17 16:39 -0700
              Re: realloc() - frequency, conditions, or experiences about relocation? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-18 06:12 +0100
              Re: realloc() - frequency, conditions, or experiences about relocation? Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-18 09:56 +0200
        Re: realloc() - frequency, conditions, or experiences about relocation? David Brown <david.brown@hesbynett.no> - 2024-06-17 20:11 +0200
    Re: realloc() - frequency, conditions, or experiences about relocation? Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-17 11:22 +0200
      Re: realloc() - frequency, conditions, or experiences about relocation? Vir Campestris <vir.campestris@invalid.invalid> - 2024-06-20 21:08 +0100
        Re: realloc() - frequency, conditions, or experiences about relocation? Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-21 21:12 +0200
          Re: realloc() - frequency, conditions, or experiences about relocation? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-24 08:40 +0000
            Re: realloc() - frequency, conditions, or experiences about relocation? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-24 02:55 -0700
              Re: realloc() - frequency, conditions, or experiences about relocation? David Brown <david.brown@hesbynett.no> - 2024-06-24 13:40 +0200
                Re: realloc() - frequency, conditions, or experiences about relocation? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-24 18:50 +0100
                  Re: realloc() - frequency, conditions, or experiences about relocation? scott@slp53.sl.home (Scott Lurndal) - 2024-06-24 18:20 +0000
                    Re: realloc() - frequency, conditions, or experiences about relocation? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-24 14:28 -0700
                      Re: realloc() - frequency, conditions, or experiences about relocation? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-25 00:22 +0100
                      Re: realloc() - frequency, conditions, or experiences about relocation? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-06-24 18:31 -0700
                  Re: realloc() - frequency, conditions, or experiences about relocation? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-25 07:06 +0000
                    Re: realloc() - frequency, conditions, or experiences about relocation? Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-25 10:38 +0200
                      Re: realloc() - frequency, conditions, or experiences about relocation? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-26 00:51 +0000
                Re: realloc() - frequency, conditions, or experiences about relocation? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-06-24 12:33 -0700
                  Re: realloc() - frequency, conditions, or experiences about relocation? Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-24 21:48 +0200
                Re: realloc() - frequency, conditions, or experiences about relocation? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-24 22:59 +0000
              Re: realloc() - frequency, conditions, or experiences about relocation? Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-24 16:19 +0200
              Re: realloc() - frequency, conditions, or experiences about relocation? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-06-25 07:02 +0000
                Re: realloc() - frequency, conditions, or experiences about relocation? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-25 03:05 -0700
                  Re: realloc() - frequency, conditions, or experiences about relocation? Richard Damon <richard@damon-family.org> - 2024-06-25 07:21 -0400
                  Re: realloc() - frequency, conditions, or experiences about relocation? Phil Carmody <pc+usenet@asdf.org> - 2024-06-28 11:01 +0300
                    Re: realloc() - frequency, conditions, or experiences about relocation? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-28 04:04 -0700
                  Re: realloc() - frequency, conditions, or experiences about relocation? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-28 06:37 -0400
                    Re: realloc() - frequency, conditions, or experiences about relocation? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-28 04:05 -0700
                Re: realloc() - frequency, conditions, or experiences about relocation? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-28 06:36 -0400
            Re: realloc() - frequency, conditions, or experiences about relocation? Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-24 16:16 +0200
              Down the hall, past the water cooler, third door on the left... (Was: realloc() - frequency, conditions, or experiences about) relocation? gazelle@shell.xmission.com (Kenny McCormack) - 2024-06-24 15:44 +0000
                Re: Down the hall, past the water cooler, third door on the left... (Was: realloc() - frequency, conditions, or experiences about) relocation? Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-24 20:16 +0200
    Re: realloc() - frequency, conditions, or experiences about relocation? David Brown <david.brown@hesbynett.no> - 2024-06-17 14:15 +0200
      Re: realloc() - frequency, conditions, or experiences about relocation? Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-17 14:18 +0200
    Re: realloc() - frequency, conditions, or experiences about relocation? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-06-17 15:21 +0200
    Re: realloc() - frequency, conditions, or experiences about relocation? scott@slp53.sl.home (Scott Lurndal) - 2024-06-17 16:50 +0000
      Re: realloc() - frequency, conditions, or experiences about relocation? Michael S <already5chosen@yahoo.com> - 2024-06-17 20:20 +0300
        Re: realloc() - frequency, conditions, or experiences about relocation? scott@slp53.sl.home (Scott Lurndal) - 2024-06-17 19:02 +0000
    Re: realloc() - frequency, conditions, or experiences about relocation? Rosario19 <Ros@invalid.invalid> - 2024-06-18 11:50 +0200
    Re: realloc() - frequency, conditions, or experiences about relocation? Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-25 10:48 +0200
      Re: realloc() - frequency, conditions, or experiences about relocation? Vir Campestris <vir.campestris@invalid.invalid> - 2024-06-25 11:55 +0100
        Re: realloc() - frequency, conditions, or experiences about relocation? Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-25 13:28 +0200
          Re: realloc() - frequency, conditions, or experiences about relocation? Vir Campestris <vir.campestris@invalid.invalid> - 2024-06-26 12:15 +0100
            Re: realloc() - frequency, conditions, or experiences about relocation? Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-26 15:01 +0200
      Re: realloc() - frequency, conditions, or experiences about relocation? DFS <nospam@dfs.com> - 2024-06-25 09:56 -0400
        Re: realloc() - frequency, conditions, or experiences about relocation? Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-25 16:16 +0200

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#386441

On Fri, 21 Jun 2024 21:12:12 +0200, Bonita Montero wrote:

> Usually you don't resize the block with a few bytes ...

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 ...

[toc] | [prev] | [next] | [standalone]

#386446

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Fri, 21 Jun 2024 21:12:12 +0200, Bonita Montero wrote:
>> Usually you don't resize the block with a few bytes ...
>
> 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.

A (perhaps) plausible way it can fail is if allocations of different
sizes are allocated from different pools.  Trying to shrink a 1000-byte
object to 100 bytes might fail if the 100-byte pool has been exhausted.
On the other hand, realloc() could just return its argument in such a
case and continue treating the object as a 1000-byte allocation.
(The allocation functions don't have to keep track of how much memory
you asked for, only how much they actually allocated, which is >= what
you asked for.)

Arguably only a poor implementation would fail on a shrinking realloc(),
but the standard permits poor implementations.

Having said all that, if realloc fails (indicated by returning a null
pointer), you still have the original pointer to the object.

Something else that occurs to me: If a shrinking realloc() never fails
in practice, then any code you write to handle a failure won't be
tested.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#386453

On 24/06/2024 11:55, Keith Thompson wrote:

> Something else that occurs to me: If a shrinking realloc() never fails
> in practice, then any code you write to handle a failure won't be
> tested.
> 

That is always a problem with allocation functions.  Have you ever known 
a non-pathological malloc() to fail?

I think, in fact, there's a good argument for ignoring the possibility 
of malloc (and calloc and realloc) failures for most PC code.  There is 
virtually no chance of failure in reality, and if you get one, there is 
almost never a sensible way to deal with it - you just kick the can down 
the road by having functions return NULL until something gives up and 
stops the program with an error message.  You might as well just let the 
OS kill the program when you try to access memory at address 0.

I've seen more than enough error handling code that has never been 
tested in practice - including error handling code with bugs that lead 
to far worse problems than just killing the program.

Of course such treatment is not appropriate for all allocations (or 
other functions that could fail).  But often I think it is better to 
write clearer and fully testable (and tested!) code which ignores 
hypothetical errors, rather than some of the untestable and untested 
jumbles that are sometimes seen in an attempt to "handle" allocation 
failures.

[toc] | [prev] | [next] | [standalone]

#386473

On 24/06/2024 12:40, David Brown wrote:
> On 24/06/2024 11:55, Keith Thompson wrote:
> 
>> Something else that occurs to me: If a shrinking realloc() never fails
>> in practice, then any code you write to handle a failure won't be
>> tested.
>>
> 
> That is always a problem with allocation functions.  Have you ever known 
> a non-pathological malloc() to fail?
> 
> I think, in fact, there's a good argument for ignoring the possibility 
> of malloc (and calloc and realloc) failures for most PC code.  There is 
> virtually no chance of failure in reality, and if you get one, there is 
> almost never a sensible way to deal with it - you just kick the can down 
> the road by having functions return NULL until something gives up and 
> stops the program with an error message.  You might as well just let the 
> OS kill the program when you try to access memory at address 0.
> 
> I've seen more than enough error handling code that has never been 
> tested in practice - including error handling code with bugs that lead 
> to far worse problems than just killing the program.
> 
> Of course such treatment is not appropriate for all allocations (or 
> other functions that could fail).  But often I think it is better to 
> write clearer and fully testable (and tested!) code which ignores 
> hypothetical errors, rather than some of the untestable and untested 
> jumbles that are sometimes seen in an attempt to "handle" allocation 
> failures.
> 
> 
Baby X has bbx_malloc() which is guaranteed never to return NULL, and 
never to return a pointer to an allocation which cannot be indexed by an 
int.

I use a "goto out_of_memory" in regular code, however.

-- 
Check out my hobby project.
http://malcolmmclean.github.io/babyxrc

[toc] | [prev] | [next] | [standalone]

#386477

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On 24/06/2024 12:40, David Brown wrote:

>> Of course such treatment is not appropriate for all allocations (or 
>> other functions that could fail).  But often I think it is better to 
>> write clearer and fully testable (and tested!) code which ignores 
>> hypothetical errors, rather than some of the untestable and untested 
>> jumbles that are sometimes seen in an attempt to "handle" allocation 
>> failures.
>> 
>> 
>Baby X has bbx_malloc() which is guaranteed never to return NULL, and 
>never to return a pointer to an allocation which cannot be indexed by an 
>int.

What do you mean by 'indexed by an int'?  So, what happens if I index
your allocation with -109235?

Or did you mean to say unsigned (or positive) int less than the
size of the allocation?

[toc] | [prev] | [next] | [standalone]

#386483

scott@slp53.sl.home (Scott Lurndal) writes:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
>>Baby X has bbx_malloc() which is guaranteed never to return NULL, and 
>>never to return a pointer to an allocation which cannot be indexed by an 
>>int.
>
> What do you mean by 'indexed by an int'?  So, what happens if I index
> your allocation with -109235?
>
> Or did you mean to say unsigned (or positive) int less than the
> size of the allocation?

If I recall correctly, Malcolm hates size_t.  I presume that
bbx_malloc() will never allocate more than INT_MAX bytes.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#386489

On 24/06/2024 22:28, Keith Thompson wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> [...]
>>> Baby X has bbx_malloc() which is guaranteed never to return NULL, and
>>> never to return a pointer to an allocation which cannot be indexed by an
>>> int.
>>
>> What do you mean by 'indexed by an int'?  So, what happens if I index
>> your allocation with -109235?
>>
>> Or did you mean to say unsigned (or positive) int less than the
>> size of the allocation?
> 
> If I recall correctly, Malcolm hates size_t.  I presume that
> bbx_malloc() will never allocate more than INT_MAX bytes.
> 
Exactly.
Currently bbx_malloc() does take a size_t, but there version in which it 
takes an int. However you get warning sif yiub try something like 
bbx_mallcc(10 * sizeof(int)) on the basis that expressin is size_t.

But if you pass either a negative number or more than iNT_MAX, it 
assumes the request is invalid and terminates with an error message.

-- 
Check out my hobby project.
http://malcolmmclean.github.io/babyxrc

[toc] | [prev] | [next] | [standalone]

#386494

On 6/24/2024 2:28 PM, Keith Thompson wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> [...]
>>> Baby X has bbx_malloc() which is guaranteed never to return NULL, and
>>> never to return a pointer to an allocation which cannot be indexed by an
>>> int.
>>
>> What do you mean by 'indexed by an int'?  So, what happens if I index
>> your allocation with -109235?
>>
>> Or did you mean to say unsigned (or positive) int less than the
>> size of the allocation?
> 
> If I recall correctly, Malcolm hates size_t.  I presume that
> bbx_malloc() will never allocate more than INT_MAX bytes.
> 

He still has to deal with bbx_malloc failing. Don't like automatically 
aborting...

bbx_malloc(INT_MAX);
bbx_malloc(INT_MAX);
bbx_malloc(INT_MAX);
...

;^)

[toc] | [prev] | [next] | [standalone]

#386496

On Mon, 24 Jun 2024 18:50:15 +0100, Malcolm McLean wrote:

> Baby X has bbx_malloc() which is guaranteed never to return NULL ...

Does it actually allocate the (physical) memory?

I wrote a memory-hog app for Android once, and found that allocating large 
amounts of memory space had very little impact on the system. Then when I 
added code to actually write data into those allocated pages, that’s when 
it really started to break into a sweat ...

[toc] | [prev] | [next] | [standalone]

#386501

Am 25.06.2024 um 09:06 schrieb Lawrence D'Oliveiro:

> I wrote a memory-hog app for Android once, and found that allocating large
> amounts of memory space had very little impact on the system. Then when I
> added code to actually write data into those allocated pages, that’s when
> it really started to break into a sweat ...

Then android is also doing overcommit.

[toc] | [prev] | [next] | [standalone]

#386541

On Tue, 25 Jun 2024 10:38:28 +0200, Bonita Montero wrote:

> Am 25.06.2024 um 09:06 schrieb Lawrence D'Oliveiro:
> 
>> I wrote a memory-hog app for Android once, and found that allocating
>> large amounts of memory space had very little impact on the system.
>> Then when I added code to actually write data into those allocated
>> pages, that’s when it really started to break into a sweat ...
> 
> Then android is also doing overcommit.

It is running a Linux kernel, and that tends to be the default setup in 
Linux.

[toc] | [prev] | [next] | [standalone]

#386479

On 6/24/2024 4:40 AM, David Brown wrote:
> On 24/06/2024 11:55, Keith Thompson wrote:
> 
>> Something else that occurs to me: If a shrinking realloc() never fails
>> in practice, then any code you write to handle a failure won't be
>> tested.
>>
> 
> That is always a problem with allocation functions.  Have you ever known 
> a non-pathological malloc() to fail?
> 
> I think, in fact, there's a good argument for ignoring the possibility 
> of malloc (and calloc and realloc) failures for most PC code.  There is 
> virtually no chance of failure in reality, and if you get one, there is 
> almost never a sensible way to deal with it - 
[...]

I have had to deal and roll with malloc failures. It put the server in 
panic mode and it started killing connections that were already timed 
out, dumping some caches (freelists of regions, ect), ect... There is a 
way to recover.

[toc] | [prev] | [next] | [standalone]

#386480

Am 24.06.2024 um 21:33 schrieb Chris M. Thomasson:
> On 6/24/2024 4:40 AM, David Brown wrote:
>> On 24/06/2024 11:55, Keith Thompson wrote:
>>
>>> Something else that occurs to me: If a shrinking realloc() never fails
>>> in practice, then any code you write to handle a failure won't be
>>> tested.
>>>
>>
>> That is always a problem with allocation functions.  Have you ever 
>> known a non-pathological malloc() to fail?
>>
>> I think, in fact, there's a good argument for ignoring the possibility 
>> of malloc (and calloc and realloc) failures for most PC code.  There 
>> is virtually no chance of failure in reality, and if you get one, 
>> there is almost never a sensible way to deal with it - 
> [...]
> 
> I have had to deal and roll with malloc failures. It put the server in 
> panic mode and it started killing connections that were already timed 
> out, dumping some caches (freelists of regions, ect), ect... There is a 
> way to recover.
> 

There are applications where you can ignore malloc()-failures /
bad_alloc since they only allocate a small amount of memory or
a lot of small allocations which sum up to a small amount of
memory.

[toc] | [prev] | [next] | [standalone]

#386486

On Mon, 24 Jun 2024 13:40:08 +0200, David Brown wrote:

> Have you ever known a non-pathological malloc() to fail?

I was once commissioned, many decades ago, to write a multispectral image 
viewer to run on old MacOS. I followed my usual memory-allocation 
discipline. The client reported how he tried to open too many images at 
once, and ran out of memory; my program reported one out-of-memory error, 
gave up trying to open the rest of the files, and gracefully recovered 
without crashing.

The program that had been supplied to him for Microsoft Windows, however, 
gave an error for *each* file it failed to open.

[toc] | [prev] | [next] | [standalone]

#386459

Am 24.06.2024 um 11:55 schrieb Keith Thompson:
> 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.

With modern memory allocators a shrink can easily fail if the shrunken
block falls into a different size class and there's no memory for a
block in this class.
mimalloc, jemalloc and TCMalloc round up the size to the next power of
two up to 8kB. If yoz have a 8kB-class block and it shrinks below 4kB
and there's no page (6kB for all mentioned allocators) for this class
and no additional pool can be allocated the shrink fails.

[toc] | [prev] | [next] | [standalone]

#386495

On Mon, 24 Jun 2024 02:55:39 -0700, Keith Thompson wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> 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. ;)

[toc] | [prev] | [next] | [standalone]

#386504

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Mon, 24 Jun 2024 02:55:39 -0700, Keith Thompson wrote:
>> Lawrence D'Oliveiro <ldo@nz.invalid> 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. ;)

What?  No, that's not what I said at all.

Suppose you do something like:

    some_type *p = malloc(BIG_VALUE);
    // ...
    p = realloc(p, SMALL_VALUE);

If the realloc() succeeds and doesn't relocate and copy the object,
you're fine.  If realloc() succeeds and *does* relocate the object, p
still points to memory that has now been deallocated, and you don't have
a pointer to the newly allocated memory.  If realloc() fails, it returns
a null pointer, but the original memory is still valid -- but again, the
assignment clobbers your only pointer to it.

I presume you can write code that handles all three possibilities, but
you can't just ignore any errors.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#386509

On 6/25/24 6:05 AM, Keith Thompson wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>> On Mon, 24 Jun 2024 02:55:39 -0700, Keith Thompson wrote:
>>> Lawrence D'Oliveiro <ldo@nz.invalid> 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. ;)
> 
> What?  No, that's not what I said at all.
> 
> Suppose you do something like:
> 
>      some_type *p = malloc(BIG_VALUE);
>      // ...
>      p = realloc(p, SMALL_VALUE);
> 
> If the realloc() succeeds and doesn't relocate and copy the object,
> you're fine.  If realloc() succeeds and *does* relocate the object, p
> still points to memory that has now been deallocated, and you don't have
> a pointer to the newly allocated memory.  If realloc() fails, it returns
> a null pointer, but the original memory is still valid -- but again, the
> assignment clobbers your only pointer to it.
> 
> I presume you can write code that handles all three possibilities, but
> you can't just ignore any errors.
> 

The idiom I always learned for realloc was something like:


some_type *p = malloc(size);
if (!p) {
   // allocation failed, do something about it. (might be just abort)
}

...

some_type *np = realloc(p, new_size);
if (np) {
     p = np;
} else {
   // p still points to old buffer, but you didn't get the new size
   // so do what you can to handle the situation.
}

// p here points to the current buffer,
// might be the old size or the new.

[toc] | [prev] | [next] | [standalone]

#386612

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Suppose you do something like:
>
>     some_type *p = malloc(BIG_VALUE);
>     // ...
>     p = realloc(p, SMALL_VALUE);
>
> ...  If realloc() succeeds and *does* relocate the object, p
> still points to memory that has now been deallocated, and you don't have
> a pointer to the newly allocated memory.

Surely some mistake?

However, such self-assignments are bad for the reasons you state later;
verify, then update.

Phil
-- 
We are no longer hunters and nomads. No longer awed and frightened, as we have
gained some understanding of the world in which we live. As such, we can cast
aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/

[toc] | [prev] | [next] | [standalone]

#386623

Phil Carmody <pc+usenet@asdf.org> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Suppose you do something like:
>>
>>     some_type *p = malloc(BIG_VALUE);
>>     // ...
>>     p = realloc(p, SMALL_VALUE);
>>
>> ...  If realloc() succeeds and *does* relocate the object, p
>> still points to memory that has now been deallocated, and you don't have
>> a pointer to the newly allocated memory.
>
> Surely some mistake?

Yes, and thanks for catching it.

If realloc() succeeds, p points to the newly allocated memory; you no
longer have a pointer to the old deallocated memory, but that's a good
thing.

I think I was describing the behavior of calling realloc(p, SMALL_VALUE)
without assigning the result to anything.

> However, such self-assignments are bad for the reasons you state later;
> verify, then update.

Right.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web