Erland Sommarskog <[EMAIL PROTECTED]> writes:
>Tassilo Von Parseval ([EMAIL PROTECTED]) writes:
>> No, SvREADONLY is totally ok.
Agreed - SvREADONLY() is always going to be there.
But when using perl's originally-for-internals macros like this
you need to realise that things may be more complex than you thought.
Taking SvREADONLY() as an example:
A. if SV is "magical" (e.g. is tie-d)
than SV may have SvREADONLY return false (not READONLY) but none
the less of you try and change the value 'tie' may not let you.
B. Note that when SV is really an HV (hash) then SvREADONLY "bit" is used
to indicate "restricted hash" which is more subtle than scalar case.
>> The question whether a macro or function
>> is documented in perlapi.pod isn't usually a strong indication for
>> anything. perlapi is far from complete. I think many of the XS authors
>> have fallen into the habit of having the perl source at hand and looking
>> up things in there, and thus short-circuiting perlapi.
I know I do that all the time. A good project for "someone" would be
to review sv.h (etc.) macros for those which lack POD-ish bits magic
that generates perlapi.pod.
>
>Thanks Tassilo!
>
>To bad that perlapi is not complete, but I guess I get the level of
>documentation that I pay for. :-)
