develooper Front page | perl.perl5.porters | Postings from October 2003

Re: Deprecating SvPVX/marking it readonly

Thread Previous | Thread Next
From:
Nick Ing-Simmons
Date:
October 27, 2003 06:51
Subject:
Re: Deprecating SvPVX/marking it readonly
Message ID:
20031027145036.7181.8@llama.elixent.com
Arthur Bergman <sky@nanisky.com> writes:
>Hi,
>
>For the future with parrot/ponie and other exciting stuff like copy on 
>write I would like to propose an internal deprecation or change of SvPVX
>
>        SvPVX   Returns a pointer to the physical string in the
>                SV.  The SV must contain a string.
>
>                        char*   SvPVX(SV* sv)
>
>
>Currently, this means that you are allowed to take a the char, and 
>change it (as long as you don't change the length), however it is 
>already not a safe operation to do since the char* might contain 
>unicode characters (so any code that uses this without checking for 
>utf8 is broken).

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().

>
>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 *" ?

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

>
>c) document it to be a read only function and export something that 
>supports unicode
>
>Arthur


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About