Mailing List Archive: Assorted comments on the Safe module

Assorted comments on the Safe module

Dec 18, 1995, 1:45 PM

Post #1 of 11 (1030 views)

I should start by saying that I've not actually used Safe yet
- but I'd like to soon...

First off I'd like to congratulate Malcolm (and Larry) on an elegant
implementation. So much power in such a small amount of code.

*** ext/Safe/Safe.xs.ORI Fri Dec 15 17:35:48 1995
--- ext/Safe/Safe.xs Fri Dec 15 16:43:51 1995
+
+ void
+ safe_call_sv(package, mask, codesv)
+ char * package
+ SV * mask
+ SV * codesv
+ CODE:
+ int i;
+ char *str;
+ STRLEN len;
+
+ ENTER;
+ SAVETMPS;
+ save_hptr(&defstash);
+ save_aptr(&endav);
+ SAVEPPTR(op_mask);
+ Newz(666, op_mask, maxo, char);
+ SAVEFREEPV(op_mask);
+ str = SvPV(mask, len);
+ for (i = 0; i < maxo && i < len; i++)
+ op_mask[i] = str[i];

Fatal error if len != maxo?

--- ext/Safe/Safe.pm Fri Dec 15 16:53:44 1995

+ =item a new namespace

+ By default, the only variables shared with
+ compartments are $_ and @_.

Since it's a glob assignment it might be worth mentioning
the '_' filehandle.

+ =item an operator mask

+ This includes masking off operators such as I<system>, I<open>,
+ I<chown>, and I<shmget> but does not mask off operators such as
+ I<print>, I<sysread> and I<E<lt>HANDLEE<gt>>.

Typo?

+ =head2 Operator masks
+
+ An operator mask exists at user-level as a string of bytes of length
+ MAXO, each of which is either 0x00 or 0x01. Here, MAXO is the number
+ of operators in the current version of perl. The subroutine MAXO()
+ (available for export by package Safe) returns the number of operators
+ in the version of perl at the time the Safe extension was B<built>.
+
+ If the Safe module is used as a dynamic extension then it should not
+ be used with a future version of perl which has a different number
+ of operators.

That is a *cricial* issue.

+ The presence of a 0x01 byte at offset B<n> of the string
+ indicates that operator number B<n> should be masked (i.e. disallowed).
+ The Safe extension makes available routines for converting from operator
+ names to operator numbers (and I<vice versa>) and for converting from a
+ list of operator names to the corresponding mask (and I<vice versa>).

I suggest that you do all the following:

- Remove or hide all support for opcode numbers. If you can't remove it
I'd suggest turning them into 'objects' (blessed ref to IV) in order
to validate that the 'number' has been obtained by looking up it's
value by name within this process and not simply hard coded by someone
trying to avoid the lookup cost in the name of efficiency.

- All operator masks should be checked for being exactly MAXO long.

- Force Safe to only work with the perl version it was built for (check
compile-time PATCHLEVEL against run-time $]).

Given the nature of the Safe module (and the fact that it should be
supplied and rebuilt with perl) I'd *much* rather it was very strict
about this than run the risk of opcode number mismatches.

+ is the root namespace to use for the compartment (defaults to
+ "Safe::Root000000000", auto-incremented for each new compartment); and

Auto-inc isn't very cheap. Why not just use a counter 1,2,3... etc?

Warn about memory leakage from undestroyed packages.

+ my $safes = "1111111111111111111111101111111111111111111111111111111111111111"
+ . "1111111111111111111111111111111111111111111111111111111111111111"
+ . "1111110011111111111011111111111111111111111111111111111101001010"
+ . "0110111111111111111111110011111111100001000000000000000000000100"
+ . "0000000000000111110000001111111110100000000000001111111111111111"
+ . "11111111111111111110";

Eeek!

I really hope that came from a script that processes the opcode lists.
As it stands now any version-mismatch checking code you add will be
totally defeated by this hard-coded list.

Ideally a 'safe' flag should be added to opcode.pl. Failing that (or
in the meantime) a file of safe opcode _names_ could be supplied with
the extension and processed into the opmask at build time. Parsing
opcode.h from $archlib/CORE would not be too hard (especially if
opcode.pl was tweaked to add numbers after the textual names).

+ sub reval {
+ my ($obj, $expr) = @_;
+ my $root = $obj->{Root};
+ my $mask = $obj->{Mask};
+ verify_mask($mask);
+
+ my $evalsub = eval sprintf(<<'EOT', $root);
+ package %s;
+ sub {
+ eval $expr;
+ }
+ EOT
+ return safe_call_sv($root, $mask, $evalsub);
+ }

This seems rather expensive. Why not do $expr = "package $root; $expr";
and avoid the double eval? Now that Larry's added perl_eval_sv() the
whole method could be moved to XS for speed.

I *really* want to see Safe included in the standard distribution and,
even with the comments above, I'd be very happy to see this release
included now (partly to raise the profile of it).

Personally I would not want to recommend it for production use until
some or all of these issues have been addressed.

Tim.

Re: Assorted comments on the Safe module [ In reply to ]

mbeattie at sable

Dec 19, 1995, 10:01 AM

Post #2 of 11 (1028 views)

Permalink

Tim Bunce writes:
>
> I should start by saying that I've not actually used Safe yet
> - but I'd like to soon...
>
> First off I'd like to congratulate Malcolm (and Larry) on an elegant
> implementation. So much power in such a small amount of code.
>
> *** ext/Safe/Safe.xs.ORI Fri Dec 15 17:35:48 1995
> --- ext/Safe/Safe.xs Fri Dec 15 16:43:51 1995
> +
> + void
> + safe_call_sv(package, mask, codesv)
> + char * package
> + SV * mask
> + SV * codesv
> + CODE:
> + int i;
> + char *str;
> + STRLEN len;
> +
> + ENTER;
> + SAVETMPS;
> + save_hptr(&defstash);
> + save_aptr(&endav);
> + SAVEPPTR(op_mask);
> + Newz(666, op_mask, maxo, char);
> + SAVEFREEPV(op_mask);
> + str = SvPV(mask, len);
> + for (i = 0; i < maxo && i < len; i++)
> + op_mask[i] = str[i];
>
> Fatal error if len != maxo?

Yes, that's now reasonable. Before this patch, MAXO was a preprocessor
constant instead of a variable so I had to consider the possibility of
someone upgrading perl (with more operators) but not Safe.so. All the
extra operators unknown to Safe.so were masked by default, of course.
Since Safe.so now has access to a reliable variable maxo, I can force
them to be the same.

> --- ext/Safe/Safe.pm Fri Dec 15 16:53:44 1995
>
> + =item a new namespace
>
> + By default, the only variables shared with
> + compartments are $_ and @_.
>
> Since it's a glob assignment it might be worth mentioning
> the '_' filehandle.

I suppose so. Then I wondered about a format called _ and how to
explain it and chickened out. I'll mention the _ filehandle then.

> + =item an operator mask
>
> + This includes masking off operators such as I<system>, I<open>,
> + I<chown>, and I<shmget> but does not mask off operators such as
> + I<print>, I<sysread> and I<E<lt>HANDLEE<gt>>.
>
> Typo?

OK.

> + =head2 Operator masks
> +
> + An operator mask exists at user-level as a string of bytes of length
> + MAXO, each of which is either 0x00 or 0x01. Here, MAXO is the number
> + of operators in the current version of perl. The subroutine MAXO()
> + (available for export by package Safe) returns the number of operators
> + in the version of perl at the time the Safe extension was B<built>.
> +
> + If the Safe module is used as a dynamic extension then it should not
> + be used with a future version of perl which has a different number
> + of operators.
>
> That is a *cricial* issue.

Halfway between crucial and critical, I gather ;-) Luckily, it's
not true anymore (see above about the maxo variable). I changed
the documentation for MAXO() but forgot to remove this bit.

> + The presence of a 0x01 byte at offset B<n> of the string
> + indicates that operator number B<n> should be masked (i.e. disallowed).
> + The Safe extension makes available routines for converting from operator
> + names to operator numbers (and I<vice versa>) and for converting from a
> + list of operator names to the corresponding mask (and I<vice versa>).
>
> I suggest that you do all the following:
>
> - Remove or hide all support for opcode numbers. If you can't remove it
> I'd suggest turning them into 'objects' (blessed ref to IV) in order
> to validate that the 'number' has been obtained by looking up it's
> value by name within this process and not simply hard coded by someone
> trying to avoid the lookup cost in the name of efficiency.

I'm a bit wary of making mask handling harder. If it's "known" and
supported to be a bitmask then people can do things like saving submasks
and oring, xoring and so on. It's like the POSIX FD_SET, FD_CLR, ...
family of macros. You have to go around the houses to handle some
cases when you'd really like it to be a straightforward bitmask
(even though it almost always really *is* a bitmask under the covers).
One might potentially want to do more bit twiddling for opmasks than
file descriptor masks, in which case it makes it even harder.

> - All operator masks should be checked for being exactly MAXO long.

OK, I can do that now.

> - Force Safe to only work with the perl version it was built for (check
> compile-time PATCHLEVEL against run-time $]).
>
> Given the nature of the Safe module (and the fact that it should be
> supplied and rebuilt with perl) I'd *much* rather it was very strict
> about this than run the risk of opcode number mismatches.

I agree that programs using Safe shouldn't cache opcode numbers
between invocations but I don't see anything wrong with doing some
lookups and calculating a submask using opcodes and bit-twiddling.
The other potential problem would be perl changing opcode numbers
of current ops: is there really any danger of that?

> + is the root namespace to use for the compartment (defaults to
> + "Safe::Root000000000", auto-incremented for each new compartment); and
>
> Auto-inc isn't very cheap. Why not just use a counter 1,2,3... etc?

It's easily fast enough (see sv_inc) and, I would think, faster than
"Safe::Root" . $count++
Anyway, I'm not worried about speed; just about generating a unique
fairly-human-readable package name per object.

> Warn about memory leakage from undestroyed packages.

What do you mean by that? The program might want to create a number
of different compartments and execute code in each or any. Like any
object, they'll probably leave cleaning up to be implicit.

>
> + my $safes = "1111111111111111111111101111111111111111111111111111111111111111"
> + . "1111111111111111111111111111111111111111111111111111111111111111"
> + . "1111110011111111111011111111111111111111111111111111111101001010"
> + . "0110111111111111111111110011111111100001000000000000000000000100"
> + . "0000000000000111110000001111111110100000000000001111111111111111"
> + . "11111111111111111110";
>
> Eeek!
>
> I really hope that came from a script that processes the opcode lists.

Yes.

> As it stands now any version-mismatch checking code you add will be
> totally defeated by this hard-coded list.

I had banked on perl keeping its opcodes for *current* operators fixed.
Maybe this was wrong? I'm not worried about new operators tacked on the
end since they're masked by default. That's why I set a mask for the
safe ones, extend with zeroes and then invert to get the default mask.

> Ideally a 'safe' flag should be added to opcode.pl. Failing that (or
> in the meantime) a file of safe opcode _names_ could be supplied with
> the extension and processed into the opmask at build time. Parsing
> opcode.h from $archlib/CORE would not be too hard (especially if
> opcode.pl was tweaked to add numbers after the textual names).

This would be ideal. Now that Safe is going to be part of perl, I don't
feel so bad about changing opcode.pl, although I'd have to look
carefully first since I haven't fiddled with that before.

> + sub reval {
> + my ($obj, $expr) = @_;
> + my $root = $obj->{Root};
> + my $mask = $obj->{Mask};
> + verify_mask($mask);
> +
> + my $evalsub = eval sprintf(<<'EOT', $root);
> + package %s;
> + sub {
> + eval $expr;
> + }
> + EOT
> + return safe_call_sv($root, $mask, $evalsub);
> + }
>
> This seems rather expensive. Why not do $expr = "package $root; $expr";
> and avoid the double eval?

I think you've just glossed over the most subtle and important bit of
the entire extension. safe_call_sv needs to do some fancy setting up
and then call an existing subroutine which lives in the namespace of
the compartment. To do that properly, the sub needs to be compiled
into the namespace after a "package" statement (because xcv_stash
"knows" the package it was compiled into), but the package is only
known at run-time. To avoid polluting the compartment namespace, it
needs to be an anonymous sub. However, the reval sub needs to be able
to get at the anonymous sub and it does so by getting it returned
from the last expression of the first eval. The anonymous sub itself
needs to use an eval to delay the compilation of the code until
safe_call_sv puts it in a special compartment, at which time the
operator mask is in place and the "root", "current" and "main::"
packages have been fixed up by safe_call_sv so that it can't escape.

I'll try and do the necessary patches for the rest of the stuff
tomorrow, but after that I'll be off to my parents-in-law over
Christmas, where I'll be without net access entirely for the first
time for a long time. I hope I can face the withdrawal symptoms.
What I need is a laptop. Hmm, now I seem to recall someone recently
mentioning a laptop and a way to get one. Maybe I'll look into it ;-)

--Malcolm

--
Malcolm Beattie <mbeattie@sable.ox.ac.uk>
Unix Systems Programmer
Oxford University Computing Services

Re: Assorted comments on the Safe module [ In reply to ]

tchrist at mox

Dec 19, 1995, 10:20 AM

Post #3 of 11 (1029 views)

Permalink

>I'll try and do the necessary patches for the rest of the stuff
>tomorrow, but after that I'll be off to my parents-in-law over
>Christmas, where I'll be without net access entirely for the first
>time for a long time. I hope I can face the withdrawal symptoms.
>What I need is a laptop. Hmm, now I seem to recall someone recently
>mentioning a laptop and a way to get one. Maybe I'll look into it ;-)

Guess what I got myself for Christmas? :-) Pity it won't arrive in time
though, so I too shall be out of commission. It's probably better that
way. Otherwise your +perl/porters mailboxen would surely overflow. :-)

Malcolm, if you or Larry or anyone else writes a good enough perl compiler
that it manages to stop people from their sempiternal whining about perl
being a dead-end language just because it won't compile into machine code,
then you have yourself a brand new shiny toy. So I have to work an extra
week? :-)

--tom

Re: Assorted comments on the Safe module [ In reply to ]

lwall at scalpel

Dec 19, 1995, 10:28 AM

Post #4 of 11 (1030 views)

Permalink

: Actually, I don't know if labels end up in the symbol table.

They don't.

Larry

Re: Assorted comments on the Safe module [ In reply to ]

merlyn at teleport

Dec 19, 1995, 10:59 AM

Post #5 of 11 (1031 views)

Permalink

>>>>> "Malcolm" == Malcolm Beattie <mbeattie@sable.ox.ac.uk> writes:

>> --- ext/Safe/Safe.pm Fri Dec 15 16:53:44 1995
>>
>> + =item a new namespace
>>
>> + By default, the only variables shared with
>> + compartments are $_ and @_.
>>
>> Since it's a glob assignment it might be worth mentioning
>> the '_' filehandle.

Malcolm> I suppose so. Then I wondered about a format called _ and how to
Malcolm> explain it and chickened out. I'll mention the _ filehandle then.

I'm stepping in to the middle, but if it's a glob assignment, you
have to worry about all eight namespaces, don't you?

scalar
array
associative array
subroutine
filehandle
directory handle
format
label

Actually, I don't know if labels end up in the symbol table. I don't
play with them that much. I know I go through this "eight namespace"
deal over and over again every week though with my students, so it's
pretty much pounded into *my* head.

Name: Randal L. Schwartz / Stonehenge Consulting Services (503)777-0095
Keywords: Perl training, UNIX[tm] consulting, video production, skiing, flying
Email: <merlyn@stonehenge.com> Snail: (Call) PGP-Key: (finger merlyn@ora.com)
Web: <A HREF="http://www.teleport.com/~merlyn/">My Home Page!</A>
Quote: "I'm telling you, if I could have five lines in my .sig, I would!" -- me

Re: Assorted comments on the Safe module [ In reply to ]

tchrist at mox

Dec 19, 1995, 11:26 AM

Post #6 of 11 (1029 views)

Permalink

>Actually, I don't know if labels end up in the symbol table. I don't
>play with them that much. I know I go through this "eight namespace"
>deal over and over again every week though with my students, so it's
>pretty much pounded into *my* head.

Use the Source, Luke.

Perl's stabs aren't octonymous, merely septanymous. Well, I had thought
it was 7, but now I wonder whether perl stabs are actually sexanymous,
since I can't see more than one place in the gp_io to hold a DIRHANDLE
separate a FILEHANDLE.

struct gp {
SV * gp_sv; /* scalar value */
U32 gp_refcnt; /* how many globs point to this? */
struct io * gp_io; /* filehandle value */
CV * gp_form; /* format value */
AV * gp_av; /* array value */
HV * gp_hv; /* associative array value */
GV * gp_egv; /* effective gv, if *glob */
CV * gp_cv; /* subroutine value */
U32 gp_cvgen; /* generational validity of cached gv_cv */
I32 gp_lastexpr; /* used by nothing_in_common() */
line_t gp_line; /* line first declared at (for -w) */
GV * gp_filegv; /* file first declared in (for -w) */
char gp_flags;
};

Oh wait, that's not where it is. It's down in the xpvio struct,
which truly does have separate places for ifp's (and maybe ofp's)
versus dirp's.

(Hm... I don't wanna talk about top and fmt and bottom. :-) (Shoulda named
them after quarks.))

This is somewhat explained in L<perlcall/Stashes>.

Yeesh.

--tom

/*
* 'Mercy!' cried Gandalf. 'If the giving of information is to be the cure
* of your inquisitiveness, I shall spend all the rest of my days answering
* you. What more do you want to know?'
* 'The names of all the stars, and of all living things, and the whole
* history of Middle-earth and Over-heaven and of the Sundering Seas,'
* laughed Pippin.
*/

Re: Assorted comments on the Safe module [ In reply to ]

tchrist at mox

Dec 19, 1995, 11:43 AM

Post #7 of 11 (1033 views)

Permalink

>Perl's stabs aren't octonymous, merely septanymous. Well, I had thought
>it was 7, but now I wonder whether perl stabs are actually sexanymous,

I guess if I'm going to use a Greek -nym prefix I really ought to use
hexa- and hepta- instead of those "sexy" Latin prefixes. :-) At least,
if you believe it a bit queer to mix your Latin and Greek phemes.

I wonder whether anyone but Larry or Malcolm noticed? I wonder what a
classical education (in the classic sense of the word) has to do with
compiler writing? I dunno. We'll see if a perl compiler ever gets
written by someone who DOESN'T know any Greek. I bet not. :-)

--tom

Re: Assorted comments on the Safe module [ In reply to ]

Tim.Bunce at ig

Dec 19, 1995, 12:24 PM

Post #8 of 11 (1034 views)

Permalink

> From: Malcolm Beattie <mbeattie@sable.ox.ac.uk>
>
> Tim Bunce writes:
> >
> > + =head2 Operator masks
> > +
> > + An operator mask exists at user-level as a string of bytes of length
> > + MAXO, each of which is either 0x00 or 0x01. Here, MAXO is the number
> > + of operators in the current version of perl. The subroutine MAXO()
> > + (available for export by package Safe) returns the number of operators
> > + in the version of perl at the time the Safe extension was B<built>.
> > +
> > + If the Safe module is used as a dynamic extension then it should not
> > + be used with a future version of perl which has a different number
> > + of operators.
> >
> > That is a *cricial* issue.
>
> Halfway between crucial and critical, I gather ;-) Luckily, it's
> not true anymore (see above about the maxo variable). I changed
> the documentation for MAXO() but forgot to remove this bit.

Note that you can't really rely on 'number of operators' as a way to
tell if any of the operators have changed. It's quite possible that one
operator could be deleted and another added in the same release.

Requireing an exact version match would avoid this issue at no cost.

> > + The presence of a 0x01 byte at offset B<n> of the string
> > + indicates that operator number B<n> should be masked (i.e. disallowed).
> > + The Safe extension makes available routines for converting from operator
> > + names to operator numbers (and I<vice versa>) and for converting from a
> > + list of operator names to the corresponding mask (and I<vice versa>).
> >
> > I suggest that you do all the following:
> >
> > - Remove or hide all support for opcode numbers. If you can't remove it
> > I'd suggest turning them into 'objects' (blessed ref to IV) in order
> > to validate that the 'number' has been obtained by looking up it's
> > value by name within this process and not simply hard coded by someone
> > trying to avoid the lookup cost in the name of efficiency.
>
> I'm a bit wary of making mask handling harder. If it's "known" and
> supported to be a bitmask then people can do things like saving submasks
> and oring, xoring and so on. It's like the POSIX FD_SET, FD_CLR, ...
> family of macros. You have to go around the houses to handle some
> cases when you'd really like it to be a straightforward bitmask
> (even though it almost always really *is* a bitmask under the covers).
> One might potentially want to do more bit twiddling for opmasks than
> file descriptor masks, in which case it makes it even harder.

> I agree that programs using Safe shouldn't cache opcode numbers
> between invocations but I don't see anything wrong with doing some
> lookups and calculating a submask using opcodes and bit-twiddling.

Actually you could still let the users manipulate the opmasks as a _whole_
but don't expose the actual implementation, just state that they can do
bit-ops _between_ opmasks but should not make any other assumptions about
the contents of an opmask.

Hardcoding opcode numbers is evil and will be a key source of insecurity
in the world of very efficiency sensitive CGI scripts for example.

Given the critical nature of Safe it must be beyond reproach, especially
given the hype surrounding Java. I believe there is 'to much' danger if
hard coded opcode numbers can be used.

If is was a Java zealot I'd gleefully point out that closedir & fork and
kill & getppid have adjacent opcodes (273 & 274 and 279 & 280) and if a
lower opcode was added or deleted you'd have a security risk.

It might be a little far fetched but it is an issue and it sows the seed
of doubt. We really don't want any doubt associated with Safe.

> The other potential problem would be perl changing opcode numbers
> of current ops: is there really any danger of that?

See below.

> > Warn about memory leakage from undestroyed packages.
>
> What do you mean by that? The program might want to create a number
> of different compartments and execute code in each or any. Like any
> object, they'll probably leave cleaning up to be implicit.

I didn't see any code to delete auto-generated (Safe::Root00000) packages.
Maybe I missed it.

> > + my $safes = "1111111111111111111111101111111111111111111111111111111111111111"
> > + . "1111111111111111111111111111111111111111111111111111111111111111"
> > + . "1111110011111111111011111111111111111111111111111111111101001010"
> > + . "0110111111111111111111110011111111100001000000000000000000000100"
> > + . "0000000000000111110000001111111110100000000000001111111111111111"
> > + . "11111111111111111110";
> >
> > Eeek!
> >
> > I really hope that came from a script that processes the opcode lists.
>
> Yes.

Good. But since it's hard coded into the .pm file it would automatically
get updated with future releases of perl.

It should be easy to get your Makefile.PL to run the opcode processing
script.

> > As it stands now any version-mismatch checking code you add will be
> > totally defeated by this hard-coded list.
>
> I had banked on perl keeping its opcodes for *current* operators fixed.
> Maybe this was wrong?

Perl's ToDo file includes 'Shrink opcode tables ...'.

> > Ideally a 'safe' flag should be added to opcode.pl. Failing that (or
> > in the meantime) a file of safe opcode _names_ could be supplied with
> > the extension and processed into the opmask at build time. Parsing
> > opcode.h from $archlib/CORE would not be too hard (especially if
> > opcode.pl was tweaked to add numbers after the textual names).
>
> This would be ideal. Now that Safe is going to be part of perl, I don't
> feel so bad about changing opcode.pl, although I'd have to look
> carefully first since I haven't fiddled with that before.

I looked at it the last time we discussed adding a 'safe' flag and decided
that it was non-trivial because of the way flags were packed - but I
didn't spend long on it (I had a low non-trivial threshold that day :-)

> > + sub reval {
> > + my ($obj, $expr) = @_;
> > + my $root = $obj->{Root};
> > + my $mask = $obj->{Mask};
> > + verify_mask($mask);
> > +
> > + my $evalsub = eval sprintf(<<'EOT', $root);
> > + package %s;
> > + sub {
> > + eval $expr;
> > + }
> > + EOT
> > + return safe_call_sv($root, $mask, $evalsub);
> > + }
> >
> > This seems rather expensive. Why not do $expr = "package $root; $expr";
> > and avoid the double eval?
>
> I think you've just glossed over the most subtle and important bit of
> the entire extension.

Ooops :-)

> safe_call_sv needs to do some fancy setting up
> and then call an existing subroutine which lives in the namespace of
> the compartment. To do that properly, the sub needs to be compiled
> into the namespace after a "package" statement (because xcv_stash
> "knows" the package it was compiled into), but the package is only
> known at run-time. To avoid polluting the compartment namespace, it
> needs to be an anonymous sub. However, the reval sub needs to be able
> to get at the anonymous sub and it does so by getting it returned
> from the last expression of the first eval. The anonymous sub itself
> needs to use an eval to delay the compilation of the code until
> safe_call_sv puts it in a special compartment, at which time the
> operator mask is in place and the "root", "current" and "main::"
> packages have been fixed up by safe_call_sv so that it can't escape.

Ah. Okay. Still seems a pity to have a double eval but I guess it's
a small price to pay. (If you moved it to XS perhaps you could
fixup the package and then call perl_eval_sv(). Just a thought.)

> I'll try and do the necessary patches for the rest of the stuff
> tomorrow, but after that I'll be off to my parents-in-law over
> Christmas, where I'll be without net access entirely for the first
> time for a long time. I hope I can face the withdrawal symptoms.

I think it's much easier if you're away. My ISP was down most of
Monday and I spent the day listening to the sound of modems dialing.
So close and yet so far!

> What I need is a laptop. Hmm, now I seem to recall someone recently
> mentioning a laptop and a way to get one. Maybe I'll look into it ;-)

I'd certainly be very interested in an OP module based on Pauls'
enhanced xsubpp.

Merry Christmas.

Tim.

Re: Assorted comments on the Safe module [ In reply to ]

Tim.Bunce at ig

Dec 19, 1995, 12:46 PM

Post #9 of 11 (1048 views)

Permalink

> From: Tom Christiansen <tchrist@mox.perl.com>
>
> >Perl's stabs aren't octonymous, merely septanymous. Well, I had thought
> >it was 7, but now I wonder whether perl stabs are actually sexanymous,
>
> I guess if I'm going to use a Greek -nym prefix I really ought to use
> hexa- and hepta- instead of those "sexy" Latin prefixes. :-) At least,
> if you believe it a bit queer to mix your Latin and Greek phemes.
>
> I wonder whether anyone but Larry or Malcolm noticed? I wonder what a
> classical education (in the classic sense of the word) has to do with
> compiler writing? I dunno. We'll see if a perl compiler ever gets
> written by someone who DOESN'T know any Greek. I bet not. :-)

If someone writes a perl compiler then their knowledge of Greek will
be the last thing on my mind!

:-)

Tim.

Re: Assorted comments on the Safe module [ In reply to ]

doughera at lafcol

Dec 19, 1995, 3:37 PM

Post #10 of 11 (1030 views)

Permalink

On Tue, 19 Dec 1995, Tom Christiansen wrote:

> I wonder whether anyone but Larry or Malcolm noticed? I wonder what a
> classical education (in the classic sense of the word) has to do with
> compiler writing? I dunno. We'll see if a perl compiler ever gets
> written by someone who DOESN'T know any Greek. I bet not. :-)

I noticed but didn't want to embarrass you :-). Though I've had little
Latin and less Greek (well virtually no Latin and definitely no Greek,
but then the allusion is lost) I'd still be inclined to call a Jesuit
education a "classical education" :-)

Andy Dougherty doughera@lafcol.lafayette.edu