Re: Deprecating SvPVX/marking it readonly

On Monday, October 27, 2003, at 02:50  pm, Nick Ing-Simmons wrote:

>
> I see what you mean - but ...
>
> Doing things "like" read() needs to do exactly that - get a writable 
> buffer
> and fill it. Encode does strange things too.
>
> Perhaps this is a red-herring though - to get a writable char * we 
> should
> say use SvGROW().
>

Or just tell it that we are going to update it.

>>
>> a) deprecate it and provide something else for getting the raw string,
>> preferably something that you can use with unicode
>
> This _is_ the raw string - we already have SvPVbyte/SvPVutf8 for 
> getting
> the string as octets/UTF-8
>
>>
>> b) document it to be a read only function
>
> And prototype as returning "const char *" ?
>
>>

Yes, or just trust people to do the right thing, nah, that seems like a 
foolish idea.

>> c) document it to be a read only function and export a char* copy
>
> Most code that uses SvPVX rather than SvPV\w+() does so to avoid copies
> and already has to check SvPOK and SvUTF8.
>
>

Yes, in the core, I am more worried about code outside the core. (In 
fact, code in the core I can change for Ponie if I need too). (And yes, 
I consider Encode part of the CORE).

I am not convinced the speed benefit is worth the extra complexity.

Arthur