Re: RFC 227 (v1) Extend the window to turn on taint mode

2000-09-15 Thread Michael G Schwern
On Fri, Sep 15, 2000 at 01:52:00AM -, Perl6 RFC Librarian wrote: > =head1 TITLE > > Extend the window to turn on taint mode As long as we're talking about tainting (this is a good idea, BTW) how does everyone feel about a few other tainting widgets... - A way to know when taint mode is on.

Re: RFC 214 (v1) Emit warnings and errors based on unoptimized code

2000-09-15 Thread Bart Lateur
On Thu, 14 Sep 2000 15:47:43 -0700, Steve Fink wrote: >Currently, toke.c turns "foo$bar" into "foo".$bar before the parser or >anything else sees it. So any features implemented in the tokenizer have >to get smarter about remembering what they did. This sound pretty much like the same problem yo

Re: Perl Implementation Language

2000-09-15 Thread raptor
> > On Tue, Sep 12, 2000 at 03:17:47PM -0400, Ken Fox wrote: > > > That's fine for the VM and the support libraries, but I'd *really* > > > like to see the parser/front-end in Perl. There are dozens of RFCs > > > that require some non-trivial extensions to the parser. It would > > > be nice to cod

Re: RFC 227 (v1) Extend the window to turn on taint mode

2000-09-15 Thread Chaim Frenkel
> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes: >> (Someone remind me, What is the point of -T if not running setuid?) JH> Being paranoid is never a bad idea because They are always out to get you. That's fine, but tell me what security breach can be caused by not having a -T? The p

Re: RFC 227 (v1) Extend the window to turn on taint mode

2000-09-15 Thread Jarkko Hietaniemi
On Fri, Sep 15, 2000 at 09:19:14AM -0400, Chaim Frenkel wrote: > > "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes: > > >> (Someone remind me, What is the point of -T if not running setuid?) > JH> Being paranoid is never a bad idea because They are always out to get you. > > That's fine

Re: RFC 227 (v1) Extend the window to turn on taint mode

2000-09-15 Thread Chaim Frenkel
> "AT" == Adam Turoff <[EMAIL PROTECTED]> writes: AT> The crux of my proposal/request is that when perl6 innards are AT> designed, -T processing is handled the same way -p and -i are. AT> That is, option processing should start out cleaner than what AT> is in 5.7.0 or what was in 5.004 (at le

Re: RFC 214 (v1) Emit warnings and errors based on unoptimized code

2000-09-15 Thread Dan Sugalski
At 10:27 PM 9/14/00 -0400, Chaim Frenkel wrote: > > "SF" == Steve Fink <[EMAIL PROTECTED]> writes: > >SF> I suspect perl can do a much better job than it does now, but if you >SF> make it a requirement, you prevent many optimizations. I think the RFC >SF> should be very specific about when it

Re: Perl Implementation Language

2000-09-15 Thread Dan Sugalski
At 02:40 PM 9/14/00 +0100, Piers Cawley wrote: >Simon Cozens <[EMAIL PROTECTED]> writes: > > > On Tue, Sep 12, 2000 at 03:17:47PM -0400, Ken Fox wrote: > > > That's fine for the VM and the support libraries, but I'd *really* > > > like to see the parser/front-end in Perl. There are dozens of RFCs

Re: Perl Implementation Language

2000-09-15 Thread Dan Sugalski
At 03:06 PM 9/14/00 +0100, Simon Cozens wrote: >On Thu, Sep 14, 2000 at 02:40:31PM +0100, Piers Cawley wrote: > > > Are there any better reasons than "It would be nice?" > > > > Can there *be* a better reason than "It would be nice"? Seriously, > > niceness is a damned fine goal. > >No, it isn't.

Re: RFC 227 (v1) Extend the window to turn on taint mode

2000-09-15 Thread Dan Sugalski
At 04:52 AM 9/15/00 -0400, Michael G Schwern wrote: >On Fri, Sep 15, 2000 at 01:52:00AM -, Perl6 RFC Librarian wrote: > > =head1 TITLE > > > > Extend the window to turn on taint mode > >As long as we're talking about tainting (this is a good idea, BTW) how >does everyone feel about a few other

Re: Perl Implementation Language

2000-09-15 Thread Dan Sugalski
At 10:07 PM 9/13/00 -0600, Nathan Torkington wrote: >Ken Fox writes: > > The dogfood theory? One of the design goals for Perl is to make text > > munging easy. Parsing falls into that category and therefore we should > > use it, i.e. eat our own dogfood. > >How about this. During design, we try t

Re: RFC 227 (v1) Extend the window to turn on taint mode

2000-09-15 Thread Dan Sugalski
At 01:15 AM 9/15/00 -0400, Adam Turoff wrote: >On Thu, Sep 14, 2000 at 10:37:40PM -0400, Chaim Frenkel wrote: > > I vaguely recall when Chip put that in. He worked pretty hard to > > adjust the command line/#! option processing. (Something about > > unsafe operations already being done before the

Re: RFC 227 (v1) Extend the window to turn on taint mode

2000-09-15 Thread Dan Sugalski
At 09:19 AM 9/15/00 -0400, Chaim Frenkel wrote: > > "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes: > > >> (Someone remind me, What is the point of -T if not running setuid?) >JH> Being paranoid is never a bad idea because They are always out to get you. > >That's fine, but tell me what

Re: Perl Implementation Language

2000-09-15 Thread Philip Newton
On Fri, 15 Sep 2000, Dan Sugalski wrote: > Doing core work in perl also has startup issues--either we need to parse > perl code every time perl starts, write the optree stuff to be > position-independent, compile perl down to native code, or embed and > process bytecode every time we start. I

Re: RFC 214 (v1) Emit warnings and errors based on unoptimized code

2000-09-15 Thread Steve Fink
Bart Lateur wrote: > > On Thu, 14 Sep 2000 15:47:43 -0700, Steve Fink wrote: > > >Currently, toke.c turns "foo$bar" into "foo".$bar before the parser or > >anything else sees it. So any features implemented in the tokenizer have > >to get smarter about remembering what they did. > > This sound

Re: RFC 227 (v1) Extend the window to turn on taint mode

2000-09-15 Thread Adam Turoff
On Fri, Sep 15, 2000 at 01:04:50PM -0400, Dan Sugalski wrote: > At 01:15 AM 9/15/00 -0400, Adam Turoff wrote: > >On Thu, Sep 14, 2000 at 10:37:40PM -0400, Chaim Frenkel wrote: > > > I vaguely recall when Chip put that in. He worked pretty hard to > > > adjust the command line/#! option processing.

Re: Perl Implementation Language

2000-09-15 Thread Simon Cozens
On Fri, Sep 15, 2000 at 12:53:29PM -0400, Dan Sugalski wrote: > The only reason I can see nice winning over fast is if nice brings in whole > new concepts to the language. (Like, say, matrix ops or Damian's currying stuf) Well, taking the idea of writing the parser in Perl, let's have a look at

Re: RFC 227 (v1) Extend the window to turn on taint mode

2000-09-15 Thread Adam Turoff
On Fri, Sep 15, 2000 at 01:03:50PM -0400, Dan Sugalski wrote: > At 04:52 AM 9/15/00 -0400, Michael G Schwern wrote: > >On Fri, Sep 15, 2000 at 01:52:00AM -, Perl6 RFC Librarian wrote: > > > =head1 TITLE > > > > > > Extend the window to turn on taint mode > > > >As long as we're talking about t

Re: RFC 227 (v1) Extend the window to turn on taint mode

2000-09-15 Thread Dan Sugalski
At 01:53 PM 9/15/00 -0400, Adam Turoff wrote: >On Fri, Sep 15, 2000 at 01:04:50PM -0400, Dan Sugalski wrote: > > At 01:15 AM 9/15/00 -0400, Adam Turoff wrote: > > >On Thu, Sep 14, 2000 at 10:37:40PM -0400, Chaim Frenkel wrote: > > > > I vaguely recall when Chip put that in. He worked pretty hard t

Re: RFC 214 (v1) Emit warnings and errors based on unoptimized code

2000-09-15 Thread Dave Storrs
It seems to me that everyone in this thread pretty much agrees that this is a good idea, but has one of the following reservations: 1) Tracking sufficient information to be able to report errors at the exact spot they happen involves bloating the optree a lot and slowing down the whole program;

Re: RFC 227 (v1) Extend the window to turn on taint mode

2000-09-15 Thread Simon Cozens
On Fri, Sep 15, 2000 at 02:11:55PM -0400, Dan Sugalski wrote: > -c in there between the load-time things > (-M, -T, -U, etc...) and the runtime things (-n, -p) I'd say -c should be last, if only to keep Abigail happy: % perl -nce '}print $.; {' -e syntax OK simon@deep-dark-truthful-mirror ~/p

Re: RFC 227 (v1) Extend the window to turn on taint mode

2000-09-15 Thread Michael G Schwern
On Fri, Sep 15, 2000 at 01:03:50PM -0400, Dan Sugalski wrote: > Take a look at the Taint modules on CPAN. Mine does just these, and I think > Tom Phoenix's does a bunch more. Tom's Taint.pm has never worked for me. I just tried installing it again and it failed a bunch of tests (in both 5.005 a

Re: RFC 227 (v1) Extend the window to turn on taint mode

2000-09-15 Thread Chaim Frenkel
> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes: JH> It may not be. Think CGI. JH> The code is running under what ever poor security measures the silly JH> subclued webmaster set it up to be, and has access to which ever files JH> yadayadayada. No command line switches there. Only t

Re: RFC 227 (v1) Extend the window to turn on taint mode

2000-09-15 Thread Chaim Frenkel
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: DS> Any time the code being executed isn't being run as the person asking for DS> its execution you can have problems. Think daemons in perl, or DS> client-server code. (Like CGI programs, or mailing-list managers) Jobs run DS> automagical

Re: RFC 227 (v1) Extend the window to turn on taint mode

2000-09-15 Thread Dan Sugalski
At 03:38 PM 9/15/00 -0400, Michael G Schwern wrote: >On Fri, Sep 15, 2000 at 01:03:50PM -0400, Dan Sugalski wrote: > > Take a look at the Taint modules on CPAN. Mine does just these, and I > think > > Tom Phoenix's does a bunch more. > >Tom's Taint.pm has never worked for me. I just tried instal

Re: RFC 227 (v1) Extend the window to turn on taint mode

2000-09-15 Thread Dan Sugalski
At 03:58 PM 9/15/00 -0400, Chaim Frenkel wrote: > > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: > >DS> Any time the code being executed isn't being run as the person asking for >DS> its execution you can have problems. Think daemons in perl, or >DS> client-server code. (Like CGI programs,

Re: RFC 214 (v1) Emit warnings and errors based on unoptimized code

2000-09-15 Thread Steve Fink
Dave Storrs wrote: > > As to solving problem #1 (which is, arguably, the bigger problem), > suppose we add a new switch to perl? I propose we add the -H switch > (mnemonic: *H*elpful errors/warnings). When -H is set, the optree would > be generated with a sufficient amount of bloat that

Re: RFC 227 (v1) Extend the window to turn on taint mode

2000-09-15 Thread Chaim Frenkel
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: >> But these all lack command line switches that are passed to perl. DS> No, they don't. Not everywhere, certainly. Command-line switches DS> can be passed to all of 'em. Not everyone counts on the magic DS> shebang line to find the command

Re: RFC 214 (v1) Emit warnings and errors based on unoptimized code

2000-09-15 Thread Chaim Frenkel
I don't believe that the optree has to be bloated. I think having the actual line number in the optree vs. having a seperate structure mapping offsets to line numbers are the same. Then an error report would be akin to error_me_this(current_op_address, "Foo didn't baz in time. Aborting")

Re: RFC 227 (v1) Extend the window to turn on taint mode

2000-09-15 Thread Adam Turoff
On Fri, Sep 15, 2000 at 05:04:23PM -0400, Chaim Frenkel wrote: > > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: > >> But these all lack command line switches that are passed to perl. > > DS> No, they don't. Not everywhere, certainly. Command-line switches > DS> can be passed to all of 'em

Re: RFC 214 (v1) Emit warnings and errors based on unoptimized code

2000-09-15 Thread Dan Sugalski
At 05:21 PM 9/15/00 -0400, Chaim Frenkel wrote: >I don't believe that the optree has to be bloated. I think having the >actual line number in the optree vs. having a seperate structure >mapping offsets to line numbers are the same. > >Then an error report would be akin to > error_me_this(c

Re: RFC 214 (v1) Emit warnings and errors based on unoptimized code

2000-09-15 Thread Nathan Torkington
Steve Fink writes: > I suspect perl can do a much better job than it does now, but if you > make it a requirement, you prevent many optimizations. I think the RFC > should be very specific about when it applies and when it gets out of > the way. I can't be more specific unless I know the optimiza

Re: Perl Implementation Language

2000-09-15 Thread David L. Nicol
Dan Sugalski wrote: > 1) How fast is the C (or whatever) code it emits likely to be? The perl-in-perl interpreter would not be a deliverable. Speed would not be its goal. It would be a reference implementation that would be easier to break and repair. An internals tutorial, if you will. So

RFC 214 (v2) Emit warnings and errors based on unoptimized code

2000-09-15 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Emit warnings and errors based on unoptimized code =head1 VERSION Maintainer: Nathan Torkington <[EMAIL PROTECTED]> Date: Sep 12 2000 Last Modified: Sep 15 2000 Mailing List: [EMAIL PROTECTED] Num

Re: RFC 227 (v1) Extend the window to turn on taint mode

2000-09-15 Thread Michael G Schwern
On Fri, Sep 15, 2000 at 02:00:04PM -0400, Adam Turoff wrote: > I'm kinda surfing the edge here. -T is definately an internals issue, > but $TAINT? taint()? is_tainted()? > > I'm not sure if they should be exposed into the language from the > internals, or if a superstudly taint.xs in stdlib i