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

Re: Deprecating SvPVX/marking it readonly

Thread Previous | Thread Next
Nick Ing-Simmons
October 27, 2003 06:51
Re: Deprecating SvPVX/marking it readonly
Message ID:
Arthur Bergman <> writes:
>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

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About