Am 18.07.2013 00:42, schrieb H. S. Teoh:
> On Thu, Jul 18, 2013 at 12:38:37AM +0200, David wrote:
>>> C does not have a native GC. I think expecting GC.calloc to be the same as stdc.calloc is fallacious. But I agree that perhaps "calloc" isn't a good name for the GC method.
>>>
>>>
>>> T
>>
>> Why not, it's exactly named like calloc, same with malloc, qalloc and free?
> [...]
> 
> Naming it as "calloc" gives the false impression that perhaps it's equivalent to C's calloc, which is not true. Which is probably why you're complaining about the different order of parameters. :)
> 
> 
> T
> 
Exactly if something is named like the C function it should behave like it.

On Thursday, 18 July 2013 at 09:55:15 UTC, David wrote:
> I use it all the time, e.g. I have an array of blocks (65536*12Byte) and
> I don't want the GC to care about this chunk of data (since it exists up
> to 961 times) but I can't just have it filled with random data ->
> calloc. Often when I was relativly new to C I always called malloc
> followed by a memset to 0, until I learned about calloc (but that's
> getting offtopic).

calloc may still be useful as a stand-alone function. The question is whether it makes sense to be part of the GC interface, which all GCs need to implement. I think it only makes sense if some GC implementations have knowledge that allows them to return 0-filled memory without actually filling it all (e.g. if it is known that the OS does it for them).

"David" <d@dav1d.de> wrote in message news:ks6m33$o9b$1@digitalmars.com...
> Why doesn't GC.calloc follow the function signature of stdc.calloc?
>
> calloc(num, size_per_element)
>
> I think this should be changed, if no reason speaks against it, I can
> look into changing this.
> Of course this will break backwards compatability, but I think this is
> worth it?

YES.  This is the memory corruption bug that I've been stuck on for the last week in the DDMD port.

Thankyou so much for bringing this up, otherwise I'd still be stuck.

Am 18.07.2013 13:49, schrieb Daniel Murphy:
> "David" <d@dav1d.de> wrote in message news:ks6m33$o9b$1@digitalmars.com...
>> Why doesn't GC.calloc follow the function signature of stdc.calloc?
>>
>> calloc(num, size_per_element)
>>
>> I think this should be changed, if no reason speaks against it, I can
>> look into changing this.
>> Of course this will break backwards compatability, but I think this is
>> worth it?
> 
> YES.  This is the memory corruption bug that I've been stuck on for the last week in the DDMD port.
> 
> Thankyou so much for bringing this up, otherwise I'd still be stuck.
> 
> 

Haha, glad I could help you! Looks like I am not the only one with this problem.

"David" <d@dav1d.de> wrote in message news:ks8lcs$184p$1@digitalmars.com...
> Am 18.07.2013 13:49, schrieb Daniel Murphy:
>> "David" <d@dav1d.de> wrote in message news:ks6m33$o9b$1@digitalmars.com...
>>> Why doesn't GC.calloc follow the function signature of stdc.calloc?
>>>
>>> calloc(num, size_per_element)
>>>
>>> I think this should be changed, if no reason speaks against it, I can
>>> look into changing this.
>>> Of course this will break backwards compatability, but I think this is
>>> worth it?
>>
>> YES.  This is the memory corruption bug that I've been stuck on for the
>> last
>> week in the DDMD port.
>>
>> Thankyou so much for bringing this up, otherwise I'd still be stuck.
>>
>>
>
> Haha, glad I could help you! Looks like I am not the only one with this problem.

Then I found this:


import core.memory;

extern(C) int printf(const char *, ...);

void main()
{
    auto data = cast(int*)GC.realloc(null, 1024 * 4);
    printf("was %d\n", GC.sizeOf(data));
    data = cast(int*)GC.realloc(data, 1025 * 4);
    printf("is %d\n", GC.sizeOf(data));
}

prints:
was 4096
is 4096

Now I'm really worried.

Am Thu, 18 Jul 2013 13:00:24 +0200
schrieb "Vladimir Panteleev" <vladimir@thecybershadow.net>:

> On Thursday, 18 July 2013 at 09:55:15 UTC, David wrote:
> > I use it all the time, e.g. I have an array of blocks
> > (65536*12Byte) and
> > I don't want the GC to care about this chunk of data (since it
> > exists up
> > to 961 times) but I can't just have it filled with random data
> > ->
> > calloc. Often when I was relativly new to C I always called
> > malloc
> > followed by a memset to 0, until I learned about calloc (but
> > that's
> > getting offtopic).
> 
> calloc may still be useful as a stand-alone function. The question is whether it makes sense to be part of the GC interface, which all GCs need to implement. I think it only makes sense if some GC implementations have knowledge that allows them to return 0-filled memory without actually filling it all (e.g. if it is known that the OS does it for them).

The calloc implemented in Linux only works like the GC.calloc
up to ~24 MiB or so. After that it does neither set anything
to zero nor does it allocate physical memory. It just gives
you X references to a read-only page filled with zeroes, that
is marked copy-on-write.
Thus with C calloc you can allocate gigabytes of "zero
initialized" memory in an instant.
But the real benefit with the C calloc > ~24 MiB is that the
memory pages don't consume RAM until you write to them.

-- 
Marco

On 18.07.2013 16:09, Daniel Murphy wrote:
> "David" <d@dav1d.de> wrote in message news:ks8lcs$184p$1@digitalmars.com...
>> Am 18.07.2013 13:49, schrieb Daniel Murphy:
>>> "David" <d@dav1d.de> wrote in message
>>> news:ks6m33$o9b$1@digitalmars.com...
>>>> Why doesn't GC.calloc follow the function signature of stdc.calloc?
>>>>
>>>> calloc(num, size_per_element)
>>>>
>>>> I think this should be changed, if no reason speaks against it, I can
>>>> look into changing this.
>>>> Of course this will break backwards compatability, but I think this is
>>>> worth it?
>>>
>>> YES.  This is the memory corruption bug that I've been stuck on for the
>>> last
>>> week in the DDMD port.
>>>
>>> Thankyou so much for bringing this up, otherwise I'd still be stuck.
>>>
>>>
>>
>> Haha, glad I could help you! Looks like I am not the only one with this
>> problem.
>
> Then I found this:
>
>
> import core.memory;
>
> extern(C) int printf(const char *, ...);
>
> void main()
> {
>      auto data = cast(int*)GC.realloc(null, 1024 * 4);
>      printf("was %d\n", GC.sizeOf(data));
>      data = cast(int*)GC.realloc(data, 1025 * 4);
>      printf("is %d\n", GC.sizeOf(data));
> }
>
> prints:
> was 4096
> is 4096
>
> Now I'm really worried.
>

This is a bad interaction of realloc and sizeOf. A related bug:

http://d.puremagic.com/issues/show_bug.cgi?id=6372

and here is a pull request:

https://github.com/D-Programming-Language/druntime/pull/547