Re: Bug in libapreq makes form elements stick to an apache child
On Fri, Nov 19, 1999 at 10:10:07AM -0800, Jeffrey Baker wrote:
>
> if (defined @foo_in) {
Generally using defined() on aggregates is a bad idea.
Tim.
Re: Bug in libapreq makes form elements stick to an apache child
On Fri, 19 Nov 1999, Jeffrey Baker wrote:
> I don't care whether Perl has allocate memory or not. All I care about
> is whether or not there are any defined entries in the list, which I
> think is most clearly expressed as 'if (defined $list[0])'. What is
> more clear than that? 'if (@list)' could certainly work because an
> empty list evaluates to 0 in a scalar context. But the code doesn't
> look like what I am intending to do.
Eh, did I miss something? If you really really want to test whether there
are any defined entries anywhere in an array then just testing the
definedness of the first entry isn't going to help. If you really wanted
to do that you could do:
if (grep {defined} @list)
which does what you say you want. 'if (defined $list[0])' would only
check the first entry. 'if (@list)' would return true if '@list = (undef,
undef)'.
-Dave
/*==
www.urth.org
we await the New Sun
==*/
Re: Bug in libapreq makes form elements stick to an apache child
Randal L. Schwartz wrote:
> "if (@foo) {...}" is *idiomatic* Perl for "are there any elements in
> @foo, and if so, do this". If you don't understand the idioms, please
> choose a more familiar language. :)
Don't you think this is a rather nasty response, smiley notwithstanding? Normally I
enjoy your posts. Not this one.
Re: Bug in libapreq makes form elements stick to an apache child
On Fri, 19 Nov 1999, Matt Sergeant wrote: > httpd -X good production solution.
Re: Bug in libapreq makes form elements stick to an apache child
> "Jeffrey" == Jeffrey Baker <[EMAIL PROTECTED]> writes:
Jeffrey> Yeah. I guess the reason I do the latter is b/c I want the code to
Jeffrey> reflect what I am actually trying to test. I don't really want to test
Jeffrey> the trueness of @foo, I want to test for it's existence. But in perl
Jeffrey> the operation is overloaded. Feh.
Jeffrey> I think I will test for defined $foo_in[0] instead.
"if (@foo) {...}" is *idiomatic* Perl for "are there any elements in
@foo, and if so, do this". If you don't understand the idioms, please
choose a more familiar language. :)
defined @bar and defined %bletch are almost never correct, and any
seasoned Perl hacker knows to watch for those as a red flag.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Bug in libapreq makes form elements stick to an apache child
Ken Williams wrote:
> Are you sure? I'm still not sure you understand about defined(@list). It
> actually tests whether Perl has allocated memory for the structure, not whether
> the structure has ever been used or anything like that. And even the present
> behavior may change without notice.
Actually that isn't what defined does. defined is supposed to indicate
whether something has a real value or not. It is not and should not be
related to whether Perl has allocated memory for it, although one
implies the other. If no memory has been allocated, then the value is
certainly undefined. However, if memory has been allocated the value
may or may not be defined.
I understand that defined doesn't work on lists and hashes. I had
simply forgotten about that bit of trivia. defined most certainly does
work on list *members* and hash *entries*. For example, 'defined
$hash{key}' is definitely going to work. Same for 'defined $array[0]'.
> When you do "my @list = &func();" and &func returns no values, @list will be an
> empty list. And it will evaluate in a boolean context to 0 (the number of
> elements), which is false. You shouldn't really care whether Perl has
> allocated memory to it or not, because different versions of Perl will give you
> different results with that test.
I don't care whether Perl has allocate memory or not. All I care about
is whether or not there are any defined entries in the list, which I
think is most clearly expressed as 'if (defined $list[0])'. What is
more clear than that? 'if (@list)' could certainly work because an
empty list evaluates to 0 in a scalar context. But the code doesn't
look like what I am intending to do.
> Finally, what if &func returns (undef, 1) or even (undef)? If you use your
> "defined $list[0]" test, you'll get a false result here, when &func actually
> did return stuff.
Obviously I need to know the calling conventions and return values for
all of my functions :) In this case the function must either return an
empty list, or a list consisting of only defined scalar values.
> Of course, I don't know your specific application, but "defined @list" is one
> of the red flags of code.
Right. As I said I simply managed to let that bit of info slip my
mind. Perhaps I should use lint or some such.
-jwb
--
Jeffrey W. Baker * [EMAIL PROTECTED]
Critical Path, Inc. * we handle the world's email * www.cp.net
415.808.8807
Re: Bug in libapreq makes form elements stick to an apache child
[EMAIL PROTECTED] (Jeffrey Baker) wrote: >Cliff Rayman wrote: >> >> `perldoc -f defined` yields a couple of sentences: >> >> You may also use C to check whether a subroutine exists, by >> saying C without parentheses. On the other hand, use >> of C upon aggregates (hashes and arrays) is not guaranteed to >> produce intuitive results, and should probably be avoided. > >I hate it when that happens. > >> why not use: >> >> if(@foo_in) >> >> instead of: >> >> if (defined @foo_in) > >Yeah. I guess the reason I do the latter is b/c I want the code to >reflect what I am actually trying to test. I don't really want to test >the trueness of @foo, I want to test for it's existence. But in perl >the operation is overloaded. Feh. > >I think I will test for defined $foo_in[0] instead. Are you sure? I'm still not sure you understand about defined(@list). It actually tests whether Perl has allocated memory for the structure, not whether the structure has ever been used or anything like that. And even the present behavior may change without notice. When you do "my @list = &func();" and &func returns no values, @list will be an empty list. And it will evaluate in a boolean context to 0 (the number of elements), which is false. You shouldn't really care whether Perl has allocated memory to it or not, because different versions of Perl will give you different results with that test. Finally, what if &func returns (undef, 1) or even (undef)? If you use your "defined $list[0]" test, you'll get a false result here, when &func actually did return stuff. Of course, I don't know your specific application, but "defined @list" is one of the red flags of code. ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: Bug in libapreq makes form elements stick to an apache child
On Fri, 19 Nov 1999, Jeffrey Baker wrote: > 1) Visit /yoururl > 2) Visit /yoururl?foo=bar&foo=baz > 3) Visit /yoururl as many times as you have Apache child processes httpd -X -- Details: FastNet Software Ltd - XML, Perl, Databases. Tagline: High Performance Web Solutions Web Sites: http://come.to/fastnet http://sergeant.org Available for Consultancy, Contracts and Training.
Re: Bug in libapreq makes form elements stick to an apache child
Cliff Rayman wrote: > > `perldoc -f defined` yields a couple of sentences: > > You may also use C to check whether a subroutine exists, by > saying C without parentheses. On the other hand, use > of C upon aggregates (hashes and arrays) is not guaranteed to > produce intuitive results, and should probably be avoided. I hate it when that happens. > why not use: > > if(@foo_in) > > instead of: > > if (defined @foo_in) Yeah. I guess the reason I do the latter is b/c I want the code to reflect what I am actually trying to test. I don't really want to test the trueness of @foo, I want to test for it's existence. But in perl the operation is overloaded. Feh. I think I will test for defined $foo_in[0] instead. -- Jeffrey W. Baker * [EMAIL PROTECTED] Critical Path, Inc. * we handle the world's email * www.cp.net 415.808.8807
Re: Bug in libapreq makes form elements stick to an apache child
`perldoc -f defined` yields a couple of sentences:
You may also use C to check whether a subroutine exists, by
saying C without parentheses. On the other hand, use
of C upon aggregates (hashes and arrays) is not guaranteed to
produce intuitive results, and should probably be avoided.
why not use:
if(@foo_in)
instead of:
if (defined @foo_in)
cliff rayman
genwax.com
Jeffrey Baker wrote:
> Hi,
>
> I haven't had time to really hunt this bug to its source, but here is
> the report anyway.
>
> Take as an example the URI /program?foo=bar&foo=baz&foo=quux
>
> In program, which uses libapreq, I have code which looks like this:
>
> my @foo_in = $r->param('foo');
>
> @foo_in should not be defined if there are no foo arguments in the query
> string. The problem is that once a foo argument has been seen, the
> @foo_in array is defined in that Apache child process for all time. The
> array will not be defined in any other Apache child.
>
> To reproduce the problem, use the handler I have included below and
> perform the following steps:
>
> 1) Visit /yoururl
> 2) Visit /yoururl?foo=bar&foo=baz
> 3) Visit /yoururl as many times as you have Apache child processes
>
> Here is the handler:
>
> package JWB;
> use Apache::Request;
>
> use strict;
>
> sub handler {
> my $r = Apache::Request->new(shift());
> $r->status(200);
> $r->content_type("text/plain");
> $r->send_http_header;
>
> my @foo_in = $r->param('foo');
>
> if (defined @foo_in) {
> print "foo_in is defined!\n";
> }
> else {
> print "foo_in is not defined!\n";
> }
>
> print "foo_in has this many entries: ",scalar(@foo_in);
>
> return 0;
> }
>
> 1;
>
> Regards,
> Jeffrey
> --
> Jeffrey W. Baker * [EMAIL PROTECTED]
> Critical Path, Inc. * we handle the world's email * www.cp.net
> 415.808.8807
Re: Bug in libapreq makes form elements stick to an apache child
I should have mentioned in this bug report that the problem only occurs
when you call $r->param in a list context. Everything is fine in a
scalar context. For that reason I suspect this little bit of code:
sub param {
my $self = shift;
my($name, $value) = @_;
my $tab = $self->parms;
unless ($name) {
my %seen;
return wantarray ? grep { !$seen{$_}++ } keys %$tab : $tab;
}
if (defined $value) {
$tab->set($name, $value);
}
return wantarray ? ($tab->get($name)) : scalar $tab->get($name);
}
-jwb
Jeffrey Baker wrote:
>
> Hi,
>
> I haven't had time to really hunt this bug to its source, but here is
> the report anyway.
>
> Take as an example the URI /program?foo=bar&foo=baz&foo=quux
>
> In program, which uses libapreq, I have code which looks like this:
>
> my @foo_in = $r->param('foo');
>
> @foo_in should not be defined if there are no foo arguments in the query
> string. The problem is that once a foo argument has been seen, the
> @foo_in array is defined in that Apache child process for all time. The
> array will not be defined in any other Apache child.
>
> To reproduce the problem, use the handler I have included below and
> perform the following steps:
>
> 1) Visit /yoururl
> 2) Visit /yoururl?foo=bar&foo=baz
> 3) Visit /yoururl as many times as you have Apache child processes
>
> Here is the handler:
>
> package JWB;
> use Apache::Request;
>
> use strict;
>
> sub handler {
> my $r = Apache::Request->new(shift());
> $r->status(200);
> $r->content_type("text/plain");
> $r->send_http_header;
>
> my @foo_in = $r->param('foo');
>
> if (defined @foo_in) {
> print "foo_in is defined!\n";
> }
> else {
> print "foo_in is not defined!\n";
> }
>
> print "foo_in has this many entries: ",scalar(@foo_in);
>
> return 0;
> }
>
> 1;
>
> Regards,
> Jeffrey
Bug in libapreq makes form elements stick to an apache child
Hi,
I haven't had time to really hunt this bug to its source, but here is
the report anyway.
Take as an example the URI /program?foo=bar&foo=baz&foo=quux
In program, which uses libapreq, I have code which looks like this:
my @foo_in = $r->param('foo');
@foo_in should not be defined if there are no foo arguments in the query
string. The problem is that once a foo argument has been seen, the
@foo_in array is defined in that Apache child process for all time. The
array will not be defined in any other Apache child.
To reproduce the problem, use the handler I have included below and
perform the following steps:
1) Visit /yoururl
2) Visit /yoururl?foo=bar&foo=baz
3) Visit /yoururl as many times as you have Apache child processes
Here is the handler:
package JWB;
use Apache::Request;
use strict;
sub handler {
my $r = Apache::Request->new(shift());
$r->status(200);
$r->content_type("text/plain");
$r->send_http_header;
my @foo_in = $r->param('foo');
if (defined @foo_in) {
print "foo_in is defined!\n";
}
else {
print "foo_in is not defined!\n";
}
print "foo_in has this many entries: ",scalar(@foo_in);
return 0;
}
1;
Regards,
Jeffrey
--
Jeffrey W. Baker * [EMAIL PROTECTED]
Critical Path, Inc. * we handle the world's email * www.cp.net
415.808.8807
