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

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

recalloc

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

Contents

  recalloc jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-21 08:32 +0200
    Re: recalloc luser droog <luser.droog@gmail.com> - 2015-06-20 23:43 -0700
      Re: recalloc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-21 10:00 +0100
        Re: recalloc luser droog <luser.droog@gmail.com> - 2015-06-21 09:57 -0700
    Re: recalloc Richard Heathfield <rjh@cpax.org.uk> - 2015-06-21 07:51 +0100
      Re: recalloc jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-21 09:22 +0200
        Re: recalloc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-21 09:49 +0100
          Re: recalloc jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-21 12:00 +0200
            Re: recalloc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-21 12:46 +0100
            Re: recalloc James Kuyper <jameskuyper@verizon.net> - 2015-06-21 12:25 -0400
              Re: recalloc David Kleinecke <dkleinecke@gmail.com> - 2015-06-22 08:27 -0700
            Re: recalloc James Kuyper <jameskuyper@verizon.net> - 2015-06-21 12:30 -0400
            Re: recalloc Keith Thompson <kst-u@mib.org> - 2015-06-21 13:00 -0700
      Re: recalloc Keith Thompson <kst-u@mib.org> - 2015-06-21 12:44 -0700
    Re: recalloc jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-21 10:30 +0200
    Re: recalloc Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-21 10:14 -0700
      Re: recalloc Richard Heathfield <rjh@cpax.org.uk> - 2015-06-21 19:28 +0100
      Re: recalloc Bartc <bc@freeuk.com> - 2015-06-21 20:10 +0100
        Re: recalloc Keith Thompson <kst-u@mib.org> - 2015-06-21 12:46 -0700
        Re: recalloc Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-21 13:41 -0700
          Re: recalloc Richard Heathfield <rjh@cpax.org.uk> - 2015-06-22 00:02 +0100
      Re: recalloc jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-21 22:59 +0200
        Re: recalloc Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-21 14:18 -0700
    Re: recalloc Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 04:50 -0700
      Re: recalloc jacobnavia <jacob@jacob.remcomp.fr> - 2015-07-11 16:18 +0200
        Re: recalloc Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 13:51 -0700
          Re: recalloc jacobnavia <jacob@jacob.remcomp.fr> - 2015-07-12 15:51 +0200
            Re: recalloc Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 03:57 -0700

Page 1 of 2  [1] 2  Next page →

#63705 — recalloc

calloc zeroes the new memory. But there is no way to re-alllocate the 
memory block WITH zeroes in the new portion, if the new size is bigger.

lcc-win introduces recalloc, with the same signature as realloc but 
zeroing the new memory.

[toc] | [next] | [standalone]

#63706

On Sunday, June 21, 2015 at 1:32:45 AM UTC-5, jacobnavia wrote:
> calloc zeroes the new memory. But there is no way to re-alllocate the 
> memory block WITH zeroes in the new portion, if the new size is bigger.
> 
> lcc-win introduces recalloc, with the same signature as realloc but 
> zeroing the new memory.

That seems like a really good idea. But what about
also accepting a void* to a fill element, size bytes of which are copied into each "word". 
This would offer a solution to the all-bits-zero-is-not-NULL
problem.

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

#63711

luser droog <luser.droog@gmail.com> writes:

> On Sunday, June 21, 2015 at 1:32:45 AM UTC-5, jacobnavia wrote:
>> calloc zeroes the new memory. But there is no way to re-alllocate the 
>> memory block WITH zeroes in the new portion, if the new size is bigger.
>> 
>> lcc-win introduces recalloc, with the same signature as realloc but 
>> zeroing the new memory.
>
> That seems like a really good idea. But what about
> also accepting a void* to a fill element, size bytes of which are
> copied into each "word".
> This would offer a solution to the all-bits-zero-is-not-NULL
> problem.

But Jacob, being the library author for a system where NULL has all bits
zero, has no all-bits-zero-is-not-NULL problem!  Complicating the
interface to a non-standard function in order to cope with a situation
that does not occur is pointless.

-- 
Ben.

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

#63729

On Sunday, June 21, 2015 at 4:00:30 AM UTC-5, Ben Bacarisse wrote:
> luser droog <luser.droog@gmail.com> writes:
> 
> > On Sunday, June 21, 2015 at 1:32:45 AM UTC-5, jacobnavia wrote:
> >> calloc zeroes the new memory. But there is no way to re-alllocate the 
> >> memory block WITH zeroes in the new portion, if the new size is bigger.
> >> 
> >> lcc-win introduces recalloc, with the same signature as realloc but 
> >> zeroing the new memory.
> >
> > That seems like a really good idea. But what about
> > also accepting a void* to a fill element, size bytes of which are
> > copied into each "word".
> > This would offer a solution to the all-bits-zero-is-not-NULL
> > problem.
> 
> But Jacob, being the library author for a system where NULL has all bits
> zero, has no all-bits-zero-is-not-NULL problem!  Complicating the
> interface to a non-standard function in order to cope with a situation
> that does not occur is pointless.
> 

Understood. But Jacob has also at times expressed a desire
to contribute to the standard. By addressing a broader issue,
we can solve more problems! That's my personal philosophy which
I hope I can intimidate others to follow.

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

#63707

On 21/06/15 07:32, jacobnavia wrote:
> calloc zeroes the new memory. But there is no way to re-alllocate the
> memory block WITH zeroes in the new portion, if the new size is bigger.
>
> lcc-win introduces recalloc, with the same signature as realloc but
> zeroing the new memory.

The name recalloc is in user namespace. Since you're the implementation, 
shouldn't you be calling it _recalloc?

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#63708

Le 21/06/2015 08:51, Richard Heathfield a écrit :
> The name recalloc is in user namespace. Since you're the implementation,
> shouldn't you be calling it _recalloc?

Yes, I will enclose the definition

#ifndef ANSIC
#endif

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

#63710

jacobnavia <jacob@jacob.remcomp.fr> writes:

> Le 21/06/2015 08:51, Richard Heathfield a écrit :
>> The name recalloc is in user namespace. Since you're the implementation,
>> shouldn't you be calling it _recalloc?
>
> Yes, I will enclose the definition
>
> #ifndef ANSIC
> #endif

Why?  ANSIC is also not a name reserved to the implementation so I'm
guessing it is something I have to "not defined" to get your new
function.  Why would I ever define it except for my own purposes?

But if you've changed the name to a reserved one, is there any need to
hide the definition at all?

-- 
Ben.

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

#63712

Le 21/06/2015 10:49, Ben Bacarisse a écrit :
> jacobnavia <jacob@jacob.remcomp.fr> writes:
>
>> Le 21/06/2015 08:51, Richard Heathfield a écrit :
>>> The name recalloc is in user namespace. Since you're the implementation,
>>> shouldn't you be calling it _recalloc?
>>
>> Yes, I will enclose the definition
>>
>> #ifndef ANSIC
>> #endif
>
> Why?  ANSIC is also not a name reserved to the implementation so I'm
> guessing it is something I have to "not defined" to get your new
> function.  Why would I ever define it except for my own purposes?
>
> But if you've changed the name to a reserved one, is there any need to
> hide the definition at all?
>

ANSIC is a symbol that you define by calling the compiler with the ANSIC 
flag. That will limit the compiler to the strict C99 standard. No 
extensions are allowed, no overloaded operators, no windows, no nothing.

It is designed for people that want strict compliance with the standard 
code.

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

#63713

jacobnavia <jacob@jacob.remcomp.fr> writes:

> Le 21/06/2015 10:49, Ben Bacarisse a écrit :
>> jacobnavia <jacob@jacob.remcomp.fr> writes:
>>
>>> Le 21/06/2015 08:51, Richard Heathfield a écrit :
>>>> The name recalloc is in user namespace. Since you're the implementation,
>>>> shouldn't you be calling it _recalloc?
>>>
>>> Yes, I will enclose the definition
>>>
>>> #ifndef ANSIC
>>> #endif
>>
>> Why?  ANSIC is also not a name reserved to the implementation so I'm
>> guessing it is something I have to "not defined" to get your new
>> function.  Why would I ever define it except for my own purposes?
>>
>> But if you've changed the name to a reserved one, is there any need to
>> hide the definition at all?
>>
>
> ANSIC is a symbol that you define by calling the compiler with the
> ANSIC flag. That will limit the compiler to the strict C99
> standard. No extensions are allowed, no overloaded operators, no
> windows, no nothing.

If you just called the function _recalloc, would you need to hide it?  I
was going to as if you really have customers who want no extraneous
identifiers (even reserved ones) defined during a compilation but
obviously, since you define at least one (ANSIC itself), you can't
have.  If they have live with ANSIC being defined, how could they mind
about _realloc?

> It is designed for people that want strict compliance with the
> standard code.

That's not possible because ANSIC is not a reserved identifier.

-- 
Ben.

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

#63721

On 06/21/2015 06:00 AM, jacobnavia wrote:
> Le 21/06/2015 10:49, Ben Bacarisse a �crit :
>> jacobnavia <jacob@jacob.remcomp.fr> writes:
>>
>>> Le 21/06/2015 08:51, Richard Heathfield a �crit :
>>>> The name recalloc is in user namespace. Since you're the implementation,
>>>> shouldn't you be calling it _recalloc?
>>>
>>> Yes, I will enclose the definition
>>>
>>> #ifndef ANSIC
>>> #endif
>>
>> Why?  ANSIC is also not a name reserved to the implementation so I'm
>> guessing it is something I have to "not defined" to get your new
>> function.  Why would I ever define it except for my own purposes?
>>
>> But if you've changed the name to a reserved one, is there any need to
>> hide the definition at all?
>>
> 
> ANSIC is a symbol that you define by calling the compiler with the ANSIC 
> flag. That will limit the compiler to the strict C99 standard. No 
> extensions are allowed, no overloaded operators, no windows, no nothing.
> 
> It is designed for people that want strict compliance with the standard 
> code.


The following is strictly conforming C code according to any version of
the C standard, from C89 to C2011 (modulo any problems with the parts
not shown):

    #ifdef ANSIA
        #define NUM_THINGS 5
    #else
        #ifdef ANSIB
            #define NUM_THINGS 7
        #else
            #ifdef ANSIC
                #define NUM_THINGS 9
            #else
                #define NUM_THINGS 11
            #endif
        #endif
    #endif
    #include <stdio.h>

    /* the rest of the code, which refers to NUM_THINGS */

This code is intended to be used with the -D option provided by every C
compiler I've ever used, to control NUM_THINGS (among other things -
otherwise -DNUM_THINGS=7 would be the simpler approach). As I understand
what you've just written, either your compiler's #definition of ANSIC
will interfere with the author's use of it, or his use of it will
interfere with your library's use of it in the standard headers, or your
compiler will refuse to allow ANSIC to be #defined by the user - I'm not
sure which. None of those options is allowed for a fully conforming
implementation of C.

As we tried to explain to David Kleinecke, the reserved name spaces were
set aside precisely to prevent such problems. You should use a reserved
identifier (such as _ANSIC) for such purposes. Technically, __STDC__
should be usable for that purpose - why didn't you use that? Does your
compiler pre-#define __STDC__ even in non-conforming mode? I can't say
that makes the mode non-conforming, because that would be redundant.
Nothing the standard says is binding on non-conforming implementations.
But to have __STDC__ pre#defined in non-conforming mode  would be
contrary to the intended meaning of __STDC__.

David is in favor of handling the possible name collisions between the
implementation and the user the same way that collisions between a user
and a third-party library are handled - outside the C standard - but
that was not the approach chosen by the C committee (for which I am
grateful).
-- 
James Kuyper

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

#63816

On Sunday, June 21, 2015 at 9:25:32 AM UTC-7, James Kuyper wrote:
> On 06/21/2015 06:00 AM, jacobnavia wrote:
> > Le 21/06/2015 10:49, Ben Bacarisse a �crit :
> >> jacobnavia <jacob@jacob.remcomp.fr> writes:
> >>
> >>> Le 21/06/2015 08:51, Richard Heathfield a �crit :
> >>>> The name recalloc is in user namespace. Since you're the implementation,
> >>>> shouldn't you be calling it _recalloc?
> >>>
> >>> Yes, I will enclose the definition
> >>>
> >>> #ifndef ANSIC
> >>> #endif
> >>
> >> Why?  ANSIC is also not a name reserved to the implementation so I'm
> >> guessing it is something I have to "not defined" to get your new
> >> function.  Why would I ever define it except for my own purposes?
> >>
> >> But if you've changed the name to a reserved one, is there any need to
> >> hide the definition at all?
> >>
> > 
> > ANSIC is a symbol that you define by calling the compiler with the ANSIC 
> > flag. That will limit the compiler to the strict C99 standard. No 
> > extensions are allowed, no overloaded operators, no windows, no nothing.
> > 
> > It is designed for people that want strict compliance with the standard 
> > code.
> 
> 
> The following is strictly conforming C code according to any version of
> the C standard, from C89 to C2011 (modulo any problems with the parts
> not shown):
> 
>     #ifdef ANSIA
>         #define NUM_THINGS 5
>     #else
>         #ifdef ANSIB
>             #define NUM_THINGS 7
>         #else
>             #ifdef ANSIC
>                 #define NUM_THINGS 9
>             #else
>                 #define NUM_THINGS 11
>             #endif
>         #endif
>     #endif
>     #include <stdio.h>
> 
>     /* the rest of the code, which refers to NUM_THINGS */
> 
> This code is intended to be used with the -D option provided by every C
> compiler I've ever used, to control NUM_THINGS (among other things -
> otherwise -DNUM_THINGS=7 would be the simpler approach). As I understand
> what you've just written, either your compiler's #definition of ANSIC
> will interfere with the author's use of it, or his use of it will
> interfere with your library's use of it in the standard headers, or your
> compiler will refuse to allow ANSIC to be #defined by the user - I'm not
> sure which. None of those options is allowed for a fully conforming
> implementation of C.
> 
> As we tried to explain to David Kleinecke, the reserved name spaces were
> set aside precisely to prevent such problems. You should use a reserved
> identifier (such as _ANSIC) for such purposes. Technically, __STDC__
> should be usable for that purpose - why didn't you use that? Does your
> compiler pre-#define __STDC__ even in non-conforming mode? I can't say
> that makes the mode non-conforming, because that would be redundant.
> Nothing the standard says is binding on non-conforming implementations.
> But to have __STDC__ pre#defined in non-conforming mode  would be
> contrary to the intended meaning of __STDC__.
> 
> David is in favor of handling the possible name collisions between the
> implementation and the user the same way that collisions between a user
> and a third-party library are handled - outside the C standard - but
> that was not the approach chosen by the C committee (for which I am
> grateful).
 
I understand what's going on. I didn't object to it. I quoted a
third party who didn't follow the rules and you objected to my quote
(I may not have made it clear it was a quote). It is a name space
problem and the standards are not in a position to make this clear.  

The basic idea I detect is that each object should belong to a
name_space, that the name space is prefixed (with following _) to
the local name and that the standard library prefix is empty.

But the idea isn't followed. It should be "_printf (...)". For
good historical reasons that's not the way it is done. The standards
committe don't seem to be able to make up their mind. I observe
that <threads.h> has three of these "name space" prefixes - thrd, 
tss and mtx - already built in.

OK. A false consistency is the hobgoblin of little minds. I can 
live with the current rules. I believe because it is absurd.

One little problem is that the standard library isn't a single
natural name space. The natural allocation is a name space for
each header and there are many headers (29, I think, in C11).

I don't expect this to ever be straightened out.

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

#63722

On 06/21/2015 06:00 AM, jacobnavia wrote:
> Le 21/06/2015 10:49, Ben Bacarisse a �crit :
>> jacobnavia <jacob@jacob.remcomp.fr> writes:
>>
>>> Le 21/06/2015 08:51, Richard Heathfield a �crit :
>>>> The name recalloc is in user namespace. Since you're the implementation,
>>>> shouldn't you be calling it _recalloc?
>>>
>>> Yes, I will enclose the definition
>>>
>>> #ifndef ANSIC
>>> #endif
>>
>> Why?  ANSIC is also not a name reserved to the implementation so I'm
>> guessing it is something I have to "not defined" to get your new
>> function.  Why would I ever define it except for my own purposes?
>>
>> But if you've changed the name to a reserved one, is there any need to
>> hide the definition at all?
>>
> 
> ANSIC is a symbol that you define by calling the compiler with the ANSIC 
> flag. That will limit the compiler to the strict C99 standard. No 
> extensions are allowed, no overloaded operators, no windows, no nothing.

Also, note: a fully conforming implementation of C99 (or any other
version of the C standard) is allowed to have a standard library
containing a function named _realloc(), with an appopriate declaration
in <stdlib.h>. You wouldn't have to turn that off to claim full conformance.
-- 
James Kuyper

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

#63743

jacobnavia <jacob@jacob.remcomp.fr> writes:
[...]
> ANSIC is a symbol that you define by calling the compiler with the ANSIC 
> flag. That will limit the compiler to the strict C99 standard. No 
> extensions are allowed, no overloaded operators, no windows, no nothing.
>
> It is designed for people that want strict compliance with the standard 
> code.

Others have mentioned that ANSIC is not in the implementation
reserved namespace.

I was about to say that it's redundant given the existence of
__STDC__ and __STDC_VERSION__, but if I understand your description
correctly it isn't.  A fully standard conforming compiler can have
extensions; ANSIC apparently disables them, making it easier to
make sure you're writing portable code.  I like the idea.

But I suggest that the name ANSIC is potentially confusing.  ANSI has
not issued a C standard of its own since 1989.  Instead, ANSI has
officially adopted each edition of the ISO C standard after it was
published (including the 1990 ISO C standard that superseded the
1989 ANSI C standard).  Strictly speaking, the standard currently
recognized by ANSI is ISO C 2011.  But for historical reasons, a lot
of people still use the term "ANSI C" to refer to the version of the
language defined by the 1989 ANSI and 1990 ISO standard documents.
And gcc's "-ansi" option still refers to the older standard; it's
equivalent to "-std=c89" or "-std=c90".  (jacob, I presume you know
all this; I'm just being thorough.)

Since your ANSIC symbol specifies conformance to the C99 standard
with no extensions, I suggest calling it something like __C99_ONLY__,
or perhaps __STRICT_C99__.  (The latter *might* be confused with
"strict conformance", which is a different concept.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#63738

Richard Heathfield <rjh@cpax.org.uk> writes:
> On 21/06/15 07:32, jacobnavia wrote:
>> calloc zeroes the new memory. But there is no way to re-alllocate the
>> memory block WITH zeroes in the new portion, if the new size is bigger.
>>
>> lcc-win introduces recalloc, with the same signature as realloc but
>> zeroing the new memory.
>
> The name recalloc is in user namespace. Since you're the implementation, 
> shouldn't you be calling it _recalloc?

Or, better IMHO, call it recalloc and declare it in a non-standard
header.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#63709

Le 21/06/2015 08:59, jacobnavia a écrit :
[snip]
Ì am reinventing the wheel. SGI has still the docs online for a 
"recalloc" function, that combines realloc and calloc.
http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=man&raw=1&fname=/usr/share/catman/p_man/cat3x/mallinfo.z

And quite some people have asked for it. For instance:

Is there anything analog to what would recalloc be?
http://www.linuxquestions.org/questions/programming-9/is-there-anything-analog-to-what-would-recalloc-be-4175428307/

Why is there no “recalloc” in the C standard?
http://stackoverflow.com/questions/28487489/why-is-there-no-recalloc-in-the-c-standard

Visual studio 2013 offers
_recalloc
with the following proto:

void *_recalloc(void *memblock,  size_t num, size_t size );

This is patterned after calloc, not realloc. I did not follow that path.

There is a Recalloc function somewhere because somebody asks how it can 
be reimplemented since other compilers do not offer it.
(http://computer-programming-forum.com/47-c-language/c9d7ddb314c60322.htm)

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

#63732

On Sunday, June 21, 2015 at 7:32:45 AM UTC+1, jacobnavia wrote:
>
> calloc zeroes the new memory. But there is no way to re-alllocate the 
> memory block WITH zeroes in the new portion, if the new size is bigger.
> 
> lcc-win introduces recalloc, with the same signature as realloc but 
> zeroing the new memory.
>
Whilst I wouldn't go as far as to say this is useless, it's not
going to be very useful either.
Typically if you call realloc() then it's because you've got
a growing buffer than you want to insert data into. So you
don't need to zero initialise the memory. Buffers allocated for
the first time, by contrast, often need to start out will all 
elements zero.
The real problem with realloc() is the temp dance you need to clean 
up in the event of an allocation failure.  

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

#63735

On 21/06/15 18:14, Malcolm McLean wrote:

<snip>

> The real problem with realloc() is the temp dance you need to clean
> up in the event of an allocation failure.

Hi, Malcolm. Wonderful weather we're having, how's the family, etc etc, 
and NO, that is not the real problem with realloc.

Here's why. Consider malloc:

/* allocate memory */
p = malloc(n * sizeof *p);
if(p != NULL)
{
   use it
}
else
{
   handle the failure
}

Now consider realloc:

t = realloc(p, new_n * sizeof *t);
if(t != NULL)
{
   p = t;
   n = new_n;
   use it
}
else
{
   handle the failure
}

Only two extra lines of code, both easy ones, and you get the awesome 
functionality of realloc. How is that a "problem" that realloc has, 
that, say, malloc or calloc don't have?

No, the real problem with realloc is the same as with malloc and calloc 
- people don't check the return value or, if they do, they consider 
bombing out to be a sane and viable programming strategy, which is quite 
possibly why my browser crashes when I try to open the nth tab (for 
unpredictable values of n).

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#63736

On 21/06/2015 18:14, Malcolm McLean wrote:
> On Sunday, June 21, 2015 at 7:32:45 AM UTC+1, jacobnavia wrote:
>>
>> calloc zeroes the new memory. But there is no way to re-alllocate the
>> memory block WITH zeroes in the new portion, if the new size is bigger.
>>
>> lcc-win introduces recalloc, with the same signature as realloc but
>> zeroing the new memory.
>>
> Whilst I wouldn't go as far as to say this is useless, it's not
> going to be very useful either.
> Typically if you call realloc() then it's because you've got
> a growing buffer than you want to insert data into. So you
> don't need to zero initialise the memory. Buffers allocated for
> the first time, by contrast, often need to start out will all
> elements zero.

You allocate space for an array of structs where you want most of the 
elements to start off at default zero values, so you use calloc.

Then you run out of entries and need to re-allocate. Are you saying that 
now it needs to be necessary to explicitly clear those extra structs 
when before it was automatic?

It anyway wouldn't make sense to have calloc that zeros new memory and a 
recalloc that doesn't.

-- 
Bartc

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

#63741

Bartc <bc@freeuk.com> writes:
[...]
> It anyway wouldn't make sense to have calloc that zeros new memory and a 
> recalloc that doesn't.

The recalloc that doesn't (necessarily) zero new memory already exists.
It's called realloc.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#63751

On Sunday, June 21, 2015 at 8:10:45 PM UTC+1, Bart wrote:
> On 21/06/2015 18:14, Malcolm McLean wrote:
>
> > Typically if you call realloc() then it's because you've got
> > a growing buffer than you want to insert data into. So you
> > don't need to zero initialise the memory. Buffers allocated for
> > the first time, by contrast, often need to start out will all
> > elements zero.
> 
> You allocate space for an array of structs where you want most of the 
> elements to start off at default zero values, so you use calloc.
> 
> Then you run out of entries and need to re-allocate. Are you saying that 
> now it needs to be necessary to explicitly clear those extra structs 
> when before it was automatic?
> 
> It anyway wouldn't make sense to have calloc that zeros new memory and a 
> recalloc that doesn't.
> 
We're counting mouse clicks on windows in our application. We don't
know how many windows will be open, so we do malloc(N * sizeof(int)).
But initially, of course, we've got no mouse clicks at all, so each
entry must be zero. So mkake that calloc(N, sizeof(int)).

So how could be have a realloc? Obviously, if the number of windows
changes. So, let's say for the sake of argument, a new window is
added. it could easily have zero clicks. But almost as likely, it's
been added because there's a click. So it starts off with one. Now
let's say, for the sake of argument, that new windows are added when 
a window is split. Does the new window have zero clicks, the same
number of clicks as its parent, half the clicks, or a proportion based
on area? Hard to say without knowing exactly why we want the data,
anything is quite likely and reasonable. But only in one situation
will zeroing out be the right thing to do, and even then, it only 
save a single write, we're not setting up a  loop.

So zeroing out reallocated memory isn't usually very useful. Not never
useful. But you need to zero out a large area when you've no data
to put in it, and you reallocate when you've more data than will fit
in the buffer.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web