[D-runtime] dup attributes?

[Steve Schveighoffer]

----- Original Message ----
> From: Sean Kelly <sean at invisibleduck.org>
> To: D's runtime library developers list <d-runtime at puremagic.com>
> Sent: Fri, August 6, 2010 3:20:02 PM
> Subject: Re: [D-runtime] dup attributes?
> 
> On Aug 6, 2010, at 5:03 AM, Steve Schveighoffer wrote:
> > 
> > Well,  let me get to the root of the problem then :)
> > 
> > The issue is that  phobos deals with void[] for things like I/O, which to me 

> > seems like  the correct type.  It allows you to pass in any array type 
>without 
>
> >  casting, and it says "I don't know what type this is".  One of these  
>functions 
>
> > is std.file.read() which reads the entire file into an array  and returns 
>that 
>
> > array as a void[].  Given that all the C  functions use void *, it seems like 
>the 
>
> > right call.  But problems  come in because void[] has the NO_SCAN bit 
>cleared, 
>
> > but this clearly  has no pointers in it (the source is a file!).  So what to 
>do?
> 
> The  buffer can be passed around as void[] but the type that's allocated should 
>be  byte[] or ubyte[].  Allocating a void[] type will make the block scannable,  
>which isn't desirable.

I believe gc_malloc is used, with the NO_SCAN bit set.  Essentially, this is the 
same as allocating a ubyte[].

> 
> > std.file.read gets around this by calling  gc_malloc directly.  However, it 
>was 
>
> > rightfully pointed out that  if one simply dups the array, or uses 
>concatenation 
>
> > with it, it  magically loses the NO_SCAN bit.  See the bug report here: 
> >  http://d.puremagic.com/issues/show_bug.cgi?id=4572
> 
> Is it really necessary  to call gc_malloc() here?  Is the reason simply to 
>avoid the zero  initialization?

Hm... good point.  I hadn't thought of the "zero-initialization" issue.  So yes, 
it is necessary to use gc_malloc.  Do you have a good reason why gc_malloc 
shouldn't be used?

-Steve