Re: Deprecating SvPVX/marking it readonly

[email protected] (Nick Ing-Simmons)
Newsgroups perl.perl5.porters,perl.ponie.dev
Message-ID <[email protected]>
Arthur Bergman <[email protected]> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.