[D-runtime] dup attributes?

[Fawzi Mohamed]

On 6-ago-10, at 14:03, Steve Schveighoffer wrote:

> ----- Original Message ----
>> From: Fawzi Mohamed <fawzi at gmx.ch>
>> To: D's runtime library developers list <d-runtime at puremagic.com>
>> Sent: Fri, August 6, 2010 7:35:57 AM
>> Subject: Re: [D-runtime] dup attributes?
>>
>> On 6-ago-10, at 13:09, Steve Schveighoffer wrote:
>>
>>> ----- Original  Message ----
>>>> From: Fawzi Mohamed <fawzi at gmx.ch>
>>>>
>>>> well it  is not so clear to me what the  flags of a~b should be  
>>>> if the flags
>> of
>>>> a & b happens to be different.
>>>> I  think that  probably always using the default type flags from  
>>>> the
>> typeinfo
>>>> for  the result is the way to go.
>>>
>>> What about an  intelligent choice?  For example, the NO_SCAN bits  
>>> should be
>>> and-ed.  That's what I was thinking.  But of course, this means N  
>>> flag
>> lookups,
>>> so there is a performance concern.
>>
>> I dislike  "intelligent choices" if they have a cost and makes  
>> dependencies
>> less local (as  here),
>> unless it is really what one would expect.
>> In this case if I use a  global void[], of ubyte[] buffer to do  
>> concatenation
>> of arbitrary types of the  results change,
>> and it is unclear how to extend the behaviour wrt. exact  scanning  
>> should be.
>> It seems a source of hard to track bugs...
>>
>> The  cost should not be really too much, but I prefer that the  
>> target type
>> "decides"  the correct flags.
>> Using templates one can make it so that the target type is  the  
>> correct one.
>> It is faster and, IMHO, logically as well founded as the   
>> alternatives,
>> thus I would keep the current behaviour (It is also less work  :).
>
> 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?

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

also tango has this problem, and I had discussed about it with kris  
exactly because
I was worried about the NO_SCAN bits would be wrong, and so I found  
ubyte[] a better
choice.
But it turns out that (at least in tango) void[] is almost only used  
to pass in a buffer where one then
either reads or writes, and never resized, so it was almost never a  
problem.
So the fact that one can cast to void[] any array easily it makes it a  
better choice than ubyte[].

Still load and get methods that load a whole file have this problem,  
and should allocate their
buffers as ubyte[] (something read by a file should *not* contain  
pointers).

Not sure if the return type of those methods should be ubyte[] after  
all (I lean a bit on yes
because calling those methods you will need to cast the void[] away,  
not cast to void[]
  as all other cases), but for sure the internal allocation should be  
of an ubyte[].

> OK, after writing all this, I'm going to change my mind :P  I just  
> realized that
> the only time, and I'm pretty sure this is the *only* time, we have  
> to worry
> about this is when you're concatenating two or more void[]'s.  This  
> corner case
> seems highly unlikely. Append doesn't have the problem, and if you  
> have casted
> your void[]'s to something else, then why not use that new type's  
> bits?  I think
> you are right, concatenation should stay as is.
>
> I guess concatenation is not an issue, and we agree that dup should  
> replicate
> the flags.
>
> OK, I'll go about making the change for dup.
ok great, it seems that sometime it is possible to reach a conclusion  
to a discussion quickly,
somehow refreshing :)

ciao
Fawzi