lowercase v in %h=(v1=>'x') -- key becomes \001 instead? #4979

p5pRT · 2002-02-07T10:44:23Z

Migrated from rt.perl.org#8454 (status was 'resolved')

Searchable as RT8454$

p5pRT · 2002-02-07T10:44:23Z

From [email protected]

Created by [email protected]

"v" followed by digits makes for a funny hash key -- the digits
become the key. This happens in the %h=( key=>value) syntax.
For instance:

perl -w -e 'my %h=(v65=>"A?",v7=>"Beep",v63=>"? indeed");' \
-e 'print keys %h'

Workaround is to quote the keys: %h=("v7" => "no beep now");

Is "v" the magic? "V" is OK..

Same thing happens with 5.6.1 under DOS. Doesn't happen with
5.5.3 under AIX.

-piper
802-769-6400

Perl Info


Flags:
    category=core
    severity=low

Site configuration information for perl v5.6.0:

Configured by jtrzepac at Tue Jul 10 09:46:08 EDT 2001.

Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration:
  Platform:
    osname=solaris, osvers=2.5.1, archname=sun4-solaris
    uname='sunos tadzu 5.5.1 generic_103640-34 sun4m sparc sunw,sparcstation-20 '
    config_args=''
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
    useperlio=undef d_sfio=undef uselargefiles=define
    use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=define
  Compiler:
    cc='cc', optimize='-O', gccversion=
    cppflags='-DSOCKS -I/usr/prod/contrib/include'
    ccflags ='-DSOCKS -I/usr/prod/contrib/include'
    stdchar='unsigned char', d_stdstdio=define, usevfork=false
    intsize=4, longsize=4, ptrsize=4, doublesize=8
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=4
    alignbytes=8, usemymalloc=y, prototype=define
  Linker and Libraries:
    ld='cc', ldflags ='-L/opt/SUNWspro/SC4.2/lib -L/usr/prod/contrib/lib'
    libpth=/opt/SUNWspro/SC4.2/lib /lib /usr/lib /usr/ccs/lib /usr/prod/contrib/lib /usr/openwin/lib
    libs=-lsocket -lnsl -ldl -lm -lc -lcrypt -lsec -lsocks -lresolv
    libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
    cccdlflags='-KPIC', lddlflags='-G -L/opt/SUNWspro/SC4.2/lib -L/usr/prod/contrib/lib'

Locally applied patches:



@INC for perl v5.6.0:
    /usr/prod/contrib/lib/perl-5.6.0/sun4-solaris
    /usr/prod/contrib/lib/perl-5.6.0
    /usr/prod/contrib/lib/perl-5.6.0/site_perl/sun4-solaris
    /usr/prod/contrib/lib/perl-5.6.0/site_perl
    /usr/prod/contrib/lib/perl-5.6.0/site_perl
    .


Environment for perl v5.6.0:
    HOME=/afs/btv/u/wpiper
    LANG=en_US.ISO8859-1
    LANGUAGE (unset)
    LC_COLLATE=en_US.ISO8859-1
    LC_CTYPE=en_US.ISO8859-1
    LC_MESSAGES=C
    LC_MONETARY=en_US.ISO8859-1
    LC_NUMERIC=en_US.ISO8859-1
    LC_TIME=en_US.ISO8859-1
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)

PATH=/afs/btv/u/wpiper/bin:/usr/bin:/usr/dt/bin:/usr/openwin/bin:/bin:/usr/ucb:.:/afs/btv/u/wpiper/shells:/usr/prod/local/bin:/usr/prod/contrib/bin:/afs/btv.ibm.com/data/frame/bin:/afs/btv.ibm.com/data/rfdkps/bin:/usr/lpp/cmvc/bin:/afs/btv/data/express/bin/net/rs6000:/afs/watson/projects/d700/emi/bin:/afs/btv.ibm.com/data/n37v/software/gnu/bin:/usr/bin/X11:/afs/btv/data/a29v/prod/bin:/afs/btv/data/cds/.cds/cds2/vmp2.4_ic443_200003190706/tools/vampire/bin:/afs/btv/data/cds/.cds/cds10/ic443_isr20000420207/tools/dfII/bin:/afs/btv/data/cds/.cds/cds10/ic443_isr20000420207/tools.ibmrs/bin:/afs/btv/data/rfdkps/cad6/sequence/2000.4PR1/bin:/afs/btv/u/gschulb/auto_place_bin:/afs/btv/data/rfdkps/cad7/ansoft:/etc:/afs/btv/data/ams/btv/@sys/bin:/usr/afsws/bin:/usr/afsws/etc:/afs/btv/@sys/prod/contrib/bin:/usr/local:/usr/etc:/usr/local/bin:/usr/local/fvwm2
    PERL_BADLANG (unset)
    SHELL=/bin/ksh

p5pRT · 2002-02-07T10:48:09Z

From [Unknown Contact. See original ticket]

On Feb 7, William Piper said:

"v" followed by digits makes for a funny hash key -- the digits
become the key. This happens in the %h=( key=>value) syntax.
For instance:

Perl 5.6 supports v-strings ("version strings").

perl -w -e 'my %h=(v65=>"A?",v7=>"Beep",v63=>"? indeed");' \
-e 'print keys %h'

Workaround is to quote the keys: %h=("v7" => "no beep now");

Is "v" the magic? "V" is OK..

So yes, the "v" is magical.

--
Jeff "japhy" Pinyan japhy@pobox.com http://www.pobox.com/~japhy/
RPI Acacia brother #734 http://www.perlmonks.org/ http://www.cpan.org/
** Look for "Regular Expressions in Perl" published by Manning, in 2002 **
<stu> what does y/// stand for? <tenderpuss> why, yansliterate of course.

p5pRT · 2002-02-07T11:12:57Z

From @schwern

On Thu, Feb 07, 2002 at 01:47:47PM -0500, Jeff 'japhy' Pinyan wrote:

On Feb 7, William Piper said:

"v" followed by digits makes for a funny hash key -- the digits
become the key. This happens in the %h=( key=>value) syntax.
For instance:

Perl 5.6 supports v-strings ("version strings").

Shouldn't the => have caused the v65 bareword to be quoted?

The => digraph is mostly just a synonym for the comma
operator. It's useful for documenting arguments that come
in pairs. As of release 5.001, it also forces any word to
the left of it to be interpreted as a string.

$ perl -wle 'my %h = (b23 => 42); print keys %h'
b23

Should v-string magic override =>'s LHS autoquoting?

--

Michael G. Schwern <schwern@pobox.com> http://www.pobox.com/~schwern/
Perl Quality Assurance <perl-qa@perl.org> Kwalitee Is Job One
Tasty, yet morally ambiguous.

p5pRT · 2002-02-07T11:28:56Z

From @JohnPeacock

Michael G Schwern wrote:

Shouldn't the => have caused the v65 bareword to be quoted?
   The => digraph is mostly just a synonym for the comma
   operator\.  It's useful for documenting arguments that come
   in pairs\.  As of release 5\.001\, it also forces any word to
   the left of it to be interpreted as a string\.
$ perl -wle 'my %h = (b23 => 42); print keys %h'
b23

Should v-string magic override =>'s LHS autoquoting?

Except that the tokenizer has already created the v-string before it even
reaches the '=>'. Technically speaking, v-strings are strings (POK) so the =>
has nothing to do (and AFAIK there is no way to undo the v-string after the
fact).

This is a documentation issue more than anything else; don't use barewords with
a leading 'v' followed by digits unless you want a v-string.

John

--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747

p5pRT · 2002-02-07T12:11:26Z

From @tamias

On Thu, Feb 07, 2002 at 02:28:21PM -0500, John Peacock wrote:

Michael G Schwern wrote:
Shouldn't the => have caused the v65 bareword to be quoted?
  The => digraph is mostly just a synonym for the comma
  operator\.  It's useful for documenting arguments that come
  in pairs\.  As of release 5\.001\, it also forces any word to
  the left of it to be interpreted as a string\.
$ perl -wle 'my %h = (b23 => 42); print keys %h'
b23

Should v-string magic override =>'s LHS autoquoting?
Except that the tokenizer has already created the v-string before it even
reaches the '=>'. Technically speaking, v-strings are strings (POK) so
the => has nothing to do (and AFAIK there is no way to undo the v-string
after the fact).

This is a documentation issue more than anything else; don't use
barewords with a leading 'v' followed by digits unless you want a
v-string.

Ugh. One more reason to dislike v-strings.

Ronald

p5pRT · 2002-02-07T12:19:13Z

From @jhi

On Thu, Feb 07, 2002 at 03:10:34PM -0500, Ronald J Kimball wrote:

On Thu, Feb 07, 2002 at 02:28:21PM -0500, John Peacock wrote:
Michael G Schwern wrote:
Shouldn't the => have caused the v65 bareword to be quoted?
  The => digraph is mostly just a synonym for the comma
  operator\.  It's useful for documenting arguments that come
  in pairs\.  As of release 5\.001\, it also forces any word to
  the left of it to be interpreted as a string\.
$ perl -wle 'my %h = (b23 => 42); print keys %h'
b23

Should v-string magic override =>'s LHS autoquoting?
Except that the tokenizer has already created the v-string before it even
reaches the '=>'. Technically speaking, v-strings are strings (POK) so
the => has nothing to do (and AFAIK there is no way to undo the v-string
after the fact).

This is a documentation issue more than anything else; don't use
barewords with a leading 'v' followed by digits unless you want a
v-string.
Ugh. One more reason to dislike v-strings.

I wasn't aware one needed any more.

Ronald

--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen

p5pRT · 2002-02-07T12:37:08Z

From @ysth

In article <20020207191209.GJ24358@blackrider>, Michael Schwern wrote:

On Thu, Feb 07, 2002 at 01:47:47PM -0500, Jeff 'japhy' Pinyan wrote:

On Feb 7, William Piper said:

"v" followed by digits makes for a funny hash key -- the digits
become the key. This happens in the %h=( key=>value) syntax.
For instance:

Perl 5.6 supports v-strings ("version strings").

Shouldn't the => have caused the v65 bareword to be quoted?
  The => digraph is mostly just a synonym for the comma
  operator\.  It's useful for documenting arguments that come
  in pairs\.  As of release 5\.001\, it also forces any word to
  the left of it to be interpreted as a string\.
$ perl -wle 'my %h = (b23 => 42); print keys %h'
b23

Should v-string magic override =>'s LHS autoquoting?

Either it shouldn't or this should be mentioned in
(5.6.2) perldelta/Perl Source Incompatibilities.

I'm inclined to think that it shouldn't. The clincher to me is
that even if there is a sub b23, "b23 =>" is interpreted as "'b23',".

p5pRT · 2002-02-07T13:04:37Z

From @jhi

I'm inclined to think that it shouldn't. The clincher to me is
that even if there is a sub b23, "b23 =>" is interpreted as "'b23',".

.... and that's the way I think it should work: the hash keys are
primarily strings, nothing fanciers. I think having to add the extra
() or the extra & is not too much to ask.

--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen

p5pRT · 2002-02-07T13:26:25Z

From @JohnPeacock

Yitzchak Scott-Thoennes wrote:

In article <20020207191209.GJ24358@blackrider>, Michael Schwern wrote:
On Thu, Feb 07, 2002 at 01:47:47PM -0500, Jeff 'japhy' Pinyan wrote:

On Feb 7, William Piper said:

"v" followed by digits makes for a funny hash key -- the digits
become the key. This happens in the %h=( key=>value) syntax.
For instance:

Perl 5.6 supports v-strings ("version strings").

Shouldn't the => have caused the v65 bareword to be quoted?
 The => digraph is mostly just a synonym for the comma
 operator\.  It's useful for documenting arguments that come
 in pairs\.  As of release 5\.001\, it also forces any word to
 the left of it to be interpreted as a string\.
$ perl -wle 'my %h = (b23 => 42); print keys %h'
b23

Should v-string magic override =>'s LHS autoquoting?
Either it shouldn't or this should be mentioned in
(5.6.2) perldelta/Perl Source Incompatibilities.

As I pointed out, the tokenizer takes care of the v-string processing
before the => can get a chance to autoquote. And, since v-strings are
technically strings (POK), there is nothing for the autoquoting to do in
any case. There is nothing strange about a hash key being 'special',
whether you mean a v-string or UTF8.

I have a series of patches (which are too large to fit in this e-mail ;~)
which make v-strings into objects, and would allow the autoquoting to
deal with them differently.

John

--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747

p5pRT · 2002-02-07T13:31:28Z

From @rgarcia

On 2002.02.07 22:03 Jarkko Hietaniemi wrote:

I'm inclined to think that it shouldn't. The clincher to me is
that even if there is a sub b23, "b23 =>" is interpreted as "'b23',".

.... and that's the way I think it should work: the hash keys are
primarily strings, nothing fanciers. I think having to add the extra
() or the extra & is not too much to ask.

Note that hash subscripts don't understand vstrings :

$ bleadperl -le '$h{"v1"}=42; print $h{v1}'
42

Having => to quote vstrings is probably doable. (But this would be an
incompatible change.)

p5pRT · 2002-02-07T13:37:18Z

From @jhi

On Thu, Feb 07, 2002 at 10:33:44PM +0100, Rafael Garcia-Suarez wrote:

On 2002.02.07 22:03 Jarkko Hietaniemi wrote:

I'm inclined to think that it shouldn't. The clincher to me is
that even if there is a sub b23, "b23 =>" is interpreted as "'b23',".

.... and that's the way I think it should work: the hash keys are
primarily strings, nothing fanciers. I think having to add the extra

s/ers/er/

() or the extra & is not too much to ask.

Note that hash subscripts don't understand vstrings :

$ bleadperl -le '$h{"v1"}=42; print $h{v1}'
42

So.... anyone want to fix a yucky feature to be even more consistently
yucky? :-)

Having => to quote vstrings is probably doable. (But this would be an
incompatible change.)

For those who like their yuckiness the way it is. I don't care either
way because my personal approach to v-strings is the proverbial
10-foot pole.

--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen

p5pRT · 2002-02-07T14:30:44Z

From @JohnPeacock

Rafael Garcia-Suarez wrote:

On 2002.02.07 22:03 Jarkko Hietaniemi wrote:

I'm inclined to think that it shouldn't. The clincher to me is
that even if there is a sub b23, "b23 =>" is interpreted as "'b23',".

.... and that's the way I think it should work: the hash keys are
primarily strings, nothing fanciers. I think having to add the extra
() or the extra & is not too much to ask.

Note that hash subscripts don't understand vstrings :

$ bleadperl -le '$h{"v1"}=42; print $h{v1}'

No, the *tokenizer* understands that anything in between the {}'s should be a
string (or quoted to become one) and hence the v-string code never comes into
play:

$ perl5.7.2.exe -Dt -le '$h{"v1"}=42; print $h{v1}'

EXECUTING...

(-e:0) enter
(-e:0) nextstate
(-e:1) const(IV(42))
(-e:1) gv(main::h)
(-e:1) rv2hv
(-e:1) const(PVIV("v1")) <- string
(-e:1) helem
(-e:1) sassign
(-e:1) nextstate
(-e:1) pushmark
(-e:1) gv(main::h)
(-e:1) rv2hv
(-e:1) const(PVIV("v1")) <- also string
(-e:1) helem
(-e:1) print
42
(-e:1) leave

The v-string path is only used when the token is potentially a number, which is
never the case with hash keys. This, however, shows that v-strings *can* be
used as hash keys:

$ perl5.7.2.exe -le '$key = v1; $h{$key}=42; print $h{$key}'

EXECUTING...

(-e:0) enter
(-e:0) nextstate
(-e:1) const(PV("\1"\0)) <- v-string
(-e:1) gvsv(main::key)
(-e:1) sassign
(-e:1) nextstate
(-e:1) const(IV(42))
(-e:1) gv(main::h)
(-e:1) rv2hv
(-e:1) gvsv(main::key)
(-e:1) helem
(-e:1) sassign
(-e:1) nextstate
(-e:1) pushmark
(-e:1) gv(main::h)
(-e:1) rv2hv
(-e:1) gvsv(main::key)
(-e:1) helem
(-e:1) print
42
(-e:1) leave

Having => to quote vstrings is probably doable. (But this would be an
incompatible change.)

I'm doubtful that it would be extremely doable because it would involve backing
up and reparsing the prior token as a string as opposed to a number.

John

--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747

p5pRT · 2002-02-07T14:38:08Z

From @tamias

On Thu, Feb 07, 2002 at 05:04:11PM -0500, John Peacock wrote:

Rafael Garcia-Suarez wrote:

On 2002.02.07 22:03 Jarkko Hietaniemi wrote:

I'm inclined to think that it shouldn't. The clincher to me is
that even if there is a sub b23, "b23 =>" is interpreted as "'b23',".

.... and that's the way I think it should work: the hash keys are
primarily strings, nothing fanciers. I think having to add the extra
() or the extra & is not too much to ask.

Note that hash subscripts don't understand vstrings :

$ bleadperl -le '$h{"v1"}=42; print $h{v1}'

No, the *tokenizer* understands that anything in between the {}'s should be
a
string (or quoted to become one) and hence the v-string code never comes
into
play:

$ perl5.7.2.exe -Dt -le '$h{"v1"}=42; print $h{v1}'

[snip]

The v-string path is only used when the token is potentially a number, which
is
never the case with hash keys. This, however, shows that v-strings *can* be
used as hash keys:

$ perl5.7.2.exe -le '$key = v1; $h{$key}=42; print $h{$key}'

This is inconsistent with the behavior of numeric literals as hash keys:

% perl -le '$h{"01"}=42; $h{1} = 1; print $h{01}'
1

Ronald

p5pRT · 2002-02-07T19:45:51Z

From @JohnPeacock

Ronald J Kimball wrote:

$ perl5.7.2.exe -le '$key = v1; $h{$key}=42; print $h{$key}'

This is inconsistent with the behavior of numeric literals as hash keys:

% perl -le '$h{"01"}=42; $h{1} = 1; print $h{01}'
1

It's not, because the numeric case jumps directly to scan_num():

toke.c:3595

/* FALL THROUGH */
case '0': case '1': case '2': case '3': case '4':
case '5': case '6': case '7': case '8': case '9':
s = scan_num(s, &yylval);

....

whereas the 'v1' case goes here:

toke.c:3680

case 'v':
if (isDIGIT(s[1]) && PL_expect != XOPERATOR) {
char *start = s;
start++;
start++;
while (isDIGIT(*start) || *start == '_')
start++;
if (*start == '.' && isDIGIT(start[1])) {
s = scan_num(s, &yylval);
TERM(THING);
}
/* avoid v123abc() or $h{v1}, allow C<print v10;> */
else if (!isALPHA(*start) && (PL_expect == XTERM || PL_expect ==
XREF || PL_expect == XSTATE)) {

Notice that line above the 'else if' where hash keys are special cased. If I am
following the twisting around her, both the if and else if fail in our case and
PL_tokenbuf contains the 'v1' as a string, which is what is taken as the key.

John

--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747

p5pRT · 2002-02-07T19:55:14Z

From @tamias

On Thu, Feb 07, 2002 at 10:44:22PM -0500, John Peacock wrote:

Ronald J Kimball wrote:

$ perl5.7.2.exe -le '$key = v1; $h{$key}=42; print $h{$key}'

This is inconsistent with the behavior of numeric literals as hash keys:

% perl -le '$h{"01"}=42; $h{1} = 1; print $h{01}'
1

It's not, because the numeric case jumps directly to scan_num():

I'd afraid I don't understand. I point out that it's inconsistent because
the behavior is different. You respond that it's not inconsistent, because
the implementation is different.

%h = ( 01 => 1 ) sets $h{'1'} to 1.
$h{01} accesses $h{'1'}.

%h = ( v1 => 1 ) sets $h{"\cA"} to 1.
$h{v1} accesses $h{'v1'}.

Ronald

p5pRT · 2002-02-08T04:13:43Z

From @iabyn

Jarkko Hietaniemi <jhi@iki.fi> wrote:

For those who like their yuckiness the way it is. I don't care either
way because my personal approach to v-strings is the proverbial
10-foot pole.

Should we deprecate V strings then?
And should we provide an alternative mechanism, eg

qv/74.65.80.72/

?????

p5pRT · 2002-02-08T06:54:06Z

From @jhi

On Fri, Feb 08, 2002 at 12:11:49PM +0000, Dave Mitchell wrote:

Jarkko Hietaniemi <jhi@iki.fi> wrote:

For those who like their yuckiness the way it is. I don't care either
way because my personal approach to v-strings is the proverbial
10-foot pole.

Should we deprecate V strings then?
And should we provide an alternative mechanism, eg

That is not really an option unless Larry says so.

qv/74.65.80.72/

?????

--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen

p5pRT · 2002-02-08T07:09:53Z

From @JohnPeacock

Ronald J Kimball wrote:

I'd afraid I don't understand. I point out that it's inconsistent because
the behavior is different. You respond that it's not inconsistent, because
the implementation is different.

%h = ( 01 => 1 ) sets $h{'1'} to 1.
$h{01} accesses $h{'1'}.

%h = ( v1 => 1 ) sets $h{"\cA"} to 1.
$h{v1} accesses $h{'v1'}.

Fair enough; when you put it that way, the second example *is* inconsistent
because the $h{v1} is special cased in the tokenizer routines as *not* creating
a v-string. The way that the tokenizer currently operates, it is likely to be
more difficult to change the current behavior of

%h = ( v1 => 1 ); # key is a v-string

into

%h = ( v1 => 1 ); # key is 'v1'

for reasons I already explained. It may *not* be as difficult to make the

$h{v1} = 6;

create a v-string as a key, instead of the string 'v1'. But someone made the
effort to specifically exclude that behavior. Which is the more abusive change?

John

--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747

p5pRT closed this as completed Nov 28, 2003

p5pRT added Severity Low distro-Solaris type-core labels Oct 18, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

lowercase v in %h=(v1=>'x') -- key becomes \001 instead? #4979

lowercase v in %h=(v1=>'x') -- key becomes \001 instead? #4979

p5pRT commented Feb 7, 2002

p5pRT commented Feb 7, 2002

p5pRT commented Feb 7, 2002

p5pRT commented Feb 7, 2002

p5pRT commented Feb 7, 2002

p5pRT commented Feb 7, 2002

p5pRT commented Feb 7, 2002

p5pRT commented Feb 7, 2002

p5pRT commented Feb 7, 2002

p5pRT commented Feb 7, 2002

p5pRT commented Feb 7, 2002

p5pRT commented Feb 7, 2002

p5pRT commented Feb 7, 2002

p5pRT commented Feb 7, 2002

p5pRT commented Feb 7, 2002

p5pRT commented Feb 7, 2002

p5pRT commented Feb 8, 2002

p5pRT commented Feb 8, 2002

p5pRT commented Feb 8, 2002

lowercase v in %h=(v1=>'x') -- key becomes \001 instead? #4979

lowercase v in %h=(v1=>'x') -- key becomes \001 instead? #4979

Comments

p5pRT commented Feb 7, 2002

p5pRT commented Feb 7, 2002

From [email protected]

Created by [email protected]

p5pRT commented Feb 7, 2002

From [Unknown Contact. See original ticket]

p5pRT commented Feb 7, 2002

From @schwern

p5pRT commented Feb 7, 2002

From @JohnPeacock

p5pRT commented Feb 7, 2002

From @tamias

p5pRT commented Feb 7, 2002

From @jhi

p5pRT commented Feb 7, 2002

From @ysth

p5pRT commented Feb 7, 2002

From @jhi

p5pRT commented Feb 7, 2002

From @JohnPeacock

p5pRT commented Feb 7, 2002

From @rgarcia

p5pRT commented Feb 7, 2002

From @jhi

p5pRT commented Feb 7, 2002

From @JohnPeacock

p5pRT commented Feb 7, 2002

From @tamias

p5pRT commented Feb 7, 2002

From @JohnPeacock

p5pRT commented Feb 7, 2002

From @tamias

p5pRT commented Feb 8, 2002

From @iabyn

p5pRT commented Feb 8, 2002

From @jhi

p5pRT commented Feb 8, 2002

From @JohnPeacock