Re: The external interface for the parser piece

Nicholas Clark <[email protected]> writes:
>> Counted strings should probably just have either a platform-native int in 
>> front, or a 32-bit int in network format, both of which should be doable on 
>> any platform that perl deals with.
>
>I agree it's do-able.
>What seems to me a good idea not to do it has entered my head.
>
>We're trying to make this an easy embedding API.
>
>For the counted length version:
>If I'm being passed a (large) block of data and a length for that block from
>an upstream source which I can't change, then I have to malloc a new block
>of length+4, copy the length into the first 4 bytes, and all that data into
>the rest.
>If I'm being passed a counted length block, easy, I pass it onwards.
>
>For the 2 parameter version:
>If I'm being passed 2 parameters, a block and its length, I pass them on.
>If I'm being passed a counted block, I read the count into one variable,
>and use the address (counted block + 4) as the address of a vanilla block.
>No malloc or copy. (And I'm assuming that in C one would actually take
>the address of the structure member, no hacky pointer arithmetic)

I agree completely. It should either be pointer,length or an 
abstract type (whatever SV is in new world, PerlIO of an in-core stream) 
which has pointer/length abstractions. The latter two have the advantage
that you can tell the UTF-8-ness (if we care) by asking them.

>
>This only applies to external APIs. Internal APIs may well benefit from
>counted length systems

Sure we may as well re-use whatever-replaces-SV rather than invent 
another counted string type.

-- 
Nick Ing-Simmons <[email protected]>
Via, but not speaking for: Texas Instruments Ltd.