> HPUX 10 gcc stdio/perlio -Uuseperlio -Dusethreads -Duseithreads
> HPUX 10 gcc stdio/perlio -DDEBUGGING -Uuseperlio -Dusethreads -Duseithreads
> t/op/time...FAILED at test 3
> ext/POSIX/t/posix...FAILED at test 20
> lib/CGI/t/carp.
On Thu 11 Apr 2002 15:50, Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote:
> > HPUX 10 gcc stdio/perlio -Uuseperlio -Dusethreads -Duseithreads
> > HPUX 10 gcc stdio/perlio -DDEBUGGING -Uuseperlio -Dusethreads -Duseithreads
> > t/op/time...FAILED at test 3
> >
On Thu, Apr 11, 2002 at 07:01:14PM -0700, Ken Neighbors wrote:
> Yes, my fix for this problem is "don't do that" anymore. However, I
> remain doubtful that this is a compile-time effect because the
> *initialization* of the variable is supposed to happen at run-time
> according to the Perl docume
Jarkko Hietaniemi wrote:
>
> On Thu, Apr 11, 2002 at 04:00:24PM -0400, Andrew Pimlott wrote:
> > This is a bug report for perl
> > generated with the help of perlbug 1.33 running under perl v5.6.1.
> >
> >
> > -
> > [Please enter you
> What about something like this:
>
> chomp(my ($class, $meth, @args) = <>);
> $class->$meth($args);
>
> And the user types in:
> rm
> POSIX::system
> -rf
> /
> ^D
>
> Is this still merely flow control?
Yes. Look it up.
Do not think that I'm saying this is an innocent or insignificant
proble
