You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Stas Bekman <st...@stason.org> on 2004/05/26 09:13:17 UTC
[mp2] unsetting members of the parsed URI record
let's say you have a uri:
my $uri = 'http://user:password@www.example.com:8000/path?args#fragment';
and you APR::URI::parse() it:
my $parsed = APR::URI::parse($r->pool, $uri);
Now you decide that the new URL shouldn't have the query and fragment fields.
So you do:
$parsed->query('');
$parsed->fragment('');
But when you call:
print $parsed->unparse;
it does not DWIM, printing:
http://user:password@www.example.com:8000/path?#
The problem is that unparse handles an empty string "" and NULL as totally
different things. "" is a perfectly valid fragment or query field. So if you
don't want '#' you must set parsed->fragment to NULL, same goes for '?' and
parsed->query. While our automatic get/set accessors happen to support
set-to-NULL mode, by passing undef as an argument, it generates a warning:
Use of uninitialized value in subroutine entry
Both, when accepting an undef as an argument and when returning one.
While, I see no problem with adjusting the API to allow passing undef to set a
certain field to NULL, I see a problem with returning undef for fields with
NULL, when a string is expected. But may be it makes a perfect sense.
I'm not sure what's the best solution here.
Anybody remembers how mp1 is dealing with those so I don't need to dig it up?
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] unsetting members of the parsed URI record
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> I just wanted to verify first if that's what we want. Next I'm going to
> fix that.
It's working now. the new accessor char is '&' and it works only for
read/write accessors of type char *.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] unsetting members of the parsed URI record
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
[...]
>>I see a problem with returning undef for
>>fields with NULL, when a string is expected. But may be it makes a
>>perfect sense.
>
>
> yeah, I need to think about that. mp1 treated undef as special in a few
> cases (see below), but that was for setting purposes - I'm not sure about
> returns. I think it is logical to return undef for NULL, rather than ''
> (which might mean "\0" or whatever that C string termination thingy is).
> but yeah, then you get warnings if you use it in various operations. but
> warnings are good - if you get back undef which throws a warning, something
> (maybe you, maybe apache) isn't doing something right, so you should account
> for it (code in a default, decide that your approach is wrong, etc).
What do you mean, not doing right? Depending on the original uri you pass to
parse() a field can be some string or NULL (undef in perl). So that means that
you always need to check whether the field is defined before using it. That's
true for optional fields like user, passoword, port, path, query and fragment.
>>I'm not sure what's the best solution here.
>>
>>Anybody remembers how mp1 is dealing with those so I don't need to dig
>>it up?
>
>
> IIRC $r->args(undef) is one case where the code needed to be changed to
> allow for specifically unsetting r->args. I don't recall the specifics, but
> it was between doug, lyle brooks, and myself, probably on dev (and in
> Changes IIRC). I know that $r->custom_response(SERVER_ERROR, undef) also is
> special, but that's not a direct slot accessor so the logic may be
> different. that's all I can think of off the top of my head. hope it helps.
>
> I don't recall it throwing a warning, which is why I asked if there is some
> way around it above. perhaps it's something about the XS wrappers that
> we're doing differently that causes the warning?
Yes, the automatic accessor wrappers can't handle undefs at the moment. That
needs to be fixed, optionally providing a special set of these that handle undefs.
I just wanted to verify first if that's what we want. Next I'm going to fix that.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] unsetting members of the parsed URI record
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> While our automatic get/set
> accessors happen to support set-to-NULL mode, by passing undef as an
> argument, it generates a warning:
>
> Use of uninitialized value in subroutine entry
>
> Both, when accepting an undef as an argument and when returning one.
hmm, that's odd. is there any way around that (see below)?
>
> While, I see no problem with adjusting the API to allow passing undef to
> set a certain field to NULL,
yes, we need that. at least we did for mp1, so I suspect the same is true
with mp2. your $parsed->query('') example is a good one - '' is very
different than null, so I would expect $parsed->query('') to behave exactly
as it does. $parsed->query(undef) should have the desired effect (well,
without the warnings :)
> I see a problem with returning undef for
> fields with NULL, when a string is expected. But may be it makes a
> perfect sense.
yeah, I need to think about that. mp1 treated undef as special in a few
cases (see below), but that was for setting purposes - I'm not sure about
returns. I think it is logical to return undef for NULL, rather than ''
(which might mean "\0" or whatever that C string termination thingy is).
but yeah, then you get warnings if you use it in various operations. but
warnings are good - if you get back undef which throws a warning, something
(maybe you, maybe apache) isn't doing something right, so you should account
for it (code in a default, decide that your approach is wrong, etc).
>
> I'm not sure what's the best solution here.
>
> Anybody remembers how mp1 is dealing with those so I don't need to dig
> it up?
IIRC $r->args(undef) is one case where the code needed to be changed to
allow for specifically unsetting r->args. I don't recall the specifics, but
it was between doug, lyle brooks, and myself, probably on dev (and in
Changes IIRC). I know that $r->custom_response(SERVER_ERROR, undef) also is
special, but that's not a direct slot accessor so the logic may be
different. that's all I can think of off the top of my head. hope it helps.
I don't recall it throwing a warning, which is why I asked if there is some
way around it above. perhaps it's something about the XS wrappers that
we're doing differently that causes the warning?
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org