Hi,
Even though this is documented, it is strange behaviour: If the from
parameter to substr()
is at, or past, the end of the input string, the
function returns false.
The function is documented as
string substr ( string string, int start [, int length])
IMHO substr()
should either
-
be changed to do like Perl, which returns an error only if start is
beyond the end (not at):
(from http://www.perldoc.com/perl5.6/pod/func/substr.html)
my $null = substr $name, 6, 2; # returns '' (no warning)
my $oops = substr $name, 7; # returns undef, with warning -
be changed to return an empty string, if start is either at or beyond
the end of the input string.
I have attached patches for both solutions.
If you don't change it to be like Perl, I think it should be noted in
the documentation (as with chop()
).
If, on the other hand, it is changed to behave like Perl, I think it
should be emphasized that you are not guaranteed that the result is a
string, because this will cause (eg. has caused us) problems when using
the result as part of the $data array to PEAR DB::execute().
Happy hacking,
Morten
--
Morten Poulsen morten-Qg2caEh8@afdelingp.dk
http://www.afdelingp.dk/
Not sure if/how this should be changed.
Isn't it a mistake to give a start position at the end or beyond the
string? In this case, doesn't it make sense to return false?
Andi
At 02:39 PM 11/19/2003 +0100, Morten Poulsen wrote:
Hi,
Even though this is documented, it is strange behaviour: If the from
parameter tosubstr()
is at, or past, the end of the input string, the
function returns false.The function is documented as
string substr ( string string, int start [, int length])IMHO
substr()
should either
be changed to do like Perl, which returns an error only if start is
beyond the end (not at):
(from http://www.perldoc.com/perl5.6/pod/func/substr.html)
my $null = substr $name, 6, 2; # returns '' (no warning)
my $oops = substr $name, 7; # returns undef, with warningbe changed to return an empty string, if start is either at or beyond
the end of the input string.I have attached patches for both solutions.
If you don't change it to be like Perl, I think it should be noted in
the documentation (as withchop()
).
If, on the other hand, it is changed to behave like Perl, I think it
should be emphasized that you are not guaranteed that the result is a
string, because this will cause (eg. has caused us) problems when using
the result as part of the $data array to PEAR DB::execute().Happy hacking,
Morten--
Morten Poulsen morten-Qg2caEh8@afdelingp.dk
http://www.afdelingp.dk/