perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: [Fwd: Re: [rfc] APR::Table & polymorphic values]
Date Thu, 05 Jun 2003 05:04:17 GMT
Joe Schaefer wrote:
> Stas Bekman <stas@stason.org> writes:
> 
> [...]
> 
> 
>>>I still don't see how that's useful here.  There's nothing wrong with the
>>>data inside apr_table.  It's the c2perl
>>>translation (newSVpv) that's causing the lossage.
>>
>>and I don't get where the lossage is :(
> 
> 
> OK- I see we're having a disconnect.  Let me try to draw a picture
> of an apr_table_entry_t that's coming from an apreq-2 parser:
> 
>                ATTRIBUTE            STORAGE (BYTES) 
> table_entry:    key -------------------+
>                                        |
>                                        v  
>                                      | f | o | o | \0
> 
>                 val -------------------+
>                                        |
>                                        |
>                                        v
>              | 12345 |   0   |   8   | b | a | r | \0 | n | o | n | e | \0
>                ^         ^       ^     ^
>                |         |       |     |
>              name     status   size  data
> 
> 
> Notice that val points to the end of an apreq_value_t struct; what's
> important here is that the location of the metadata (ie. the rest of
> the apreq_value_t struct) is directly in front of *val.

Thanks for the drawing. Now I don't understand how do you get to the 
apreq_value_t pointer from table_entry->val. Do you just subtract the size of 
the apreq_value_t struct and based on the knowledge that the memory allocation 
is continues, you magically retrieve the whole struct? I think I understand 
the trick now. it wasn't obvious at all ;)

and since newSVpv copies the string, you no longer can get to the beginning of 
the struct. Now I understand why you wanted to mark it as SvFAKE (that would 
prevent the copy).

Now that I understand this thing I can think intelligently ;) For example how 
about making SV into a dual-var, ala $!. it might not work if IV slot is used 
to store the original pointer, since using val in the numeric context will 
need to make use of this field. Same with NV? I'm just thinking how can we 
save the overhead of messing with MAGIC if we can.

So you say that due to the bug we can't sub-class get() to do newSVpv while 
using the pointer to apreq_value_t and then setting SvCUR to the real string?

>>That's cool. But Joe, you don't seem to understand what I'm asking you
>>about. I want to see an example of a conversion function where this
>>meta data kicks in. 
> 
> 
> I don't know if I've said enough to answer your question, but
> I hope I've explained the problem with newSVpv well enough.
> Short of coding up an entire APR::Table subclass, can you be
> more specific about what you'd like to see?
> 
> 
>>I don't seem to get into your head to see things the same way you do.
> 
> 
> Dreadfully laconic, I know.  Sorry about that.  
> My thesis advisor used to say the same thing :-/.

I think that I'm game now ;) The drawing made things clear.


__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message