Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the YAML-LibYAML CPAN distribution.

Report information
The Basics
Id: 65662
Status: open
Priority: 0/
Queue: YAML-LibYAML

People
Owner: Nobody in particular
Requestors: mschwern [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 0.34
Fixed in: (no value)



Subject: Keys are being interpreted as booleans
YAML::XS is interpreting unquoted keys of "true" and "false" and "null" as boolean values. For example: $ perl -wlE 'use YAML::XS; say Dump(Load("{ true: 2, false: 3, null: 4 }"))' Use of uninitialized value in subroutine entry at -e line 1. --- '': 4 '1': 2 This becomes a problem if one depends on true.pm. I don't know if this contravenes the spec to interpret keys as booleans, presumably it does as there's not much use for it. It's different from how YAML.pm, YAML::Tiny and JSON::XS do it. To add complications, YAML::Tiny does not allow quoted keys, so there's no work around for the major YAML parsers. Here is a test demonstrating the problem: { my $yaml = <<'...'; --- true: 2 false: 4 null: 6 ... my $hash = Load $yaml; is_deeply $hash, { true => 2, false => 4, null => 6 }, "keys are not interpreted as booleans"; }
Subject: Re: [rt.cpan.org #65662] Keys are being interpreted as booleans
Date: Fri, 11 Feb 2011 22:00:28 -0800
To: bug-YAML-LibYAML [...] rt.cpan.org
From: Ingy dot Net <ingy [...] ingy.net>
Unquoted values are subject to "implicit typing". That means that it is up to the Loader to determine what they get loaded as. Numbers, boolean and null are respected due to JSON compatibility. YAML::XS is arguably doing the best thing. However, since booleans can never be keys in JSON, it might make sense to have the YAML loaders do make all keys strings by default. I'll gladly take a patch to this effect, or possibly get a chance to look at it next week. On Fri, Feb 11, 2011 at 3:24 PM, Michael G Schwern via RT < bug-YAML-LibYAML@rt.cpan.org> wrote: Show quoted text
> Fri Feb 11 18:24:03 2011: Request 65662 was acted upon. > Transaction: Ticket created by MSCHWERN > Queue: YAML-LibYAML > Subject: Keys are being interpreted as booleans > Broken in: 0.34 > Severity: Important > Owner: Nobody > Requestors: mschwern@cpan.org > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=65662 > > > > YAML::XS is interpreting unquoted keys of "true" and "false" and "null" > as boolean values. For example: > > $ perl -wlE 'use YAML::XS; say Dump(Load("{ true: 2, false: 3, null: > 4 }"))' > Use of uninitialized value in subroutine entry at -e line 1. > --- > '': 4 > '1': 2 > > This becomes a problem if one depends on true.pm. > > I don't know if this contravenes the spec to interpret keys as booleans, > presumably it does as there's not much use for it. It's different from > how YAML.pm, YAML::Tiny and JSON::XS do it. > > To add complications, YAML::Tiny does not allow quoted keys, so there's > no work around for the major YAML parsers. > > Here is a test demonstrating the problem: > > { > my $yaml = <<'...'; > --- > true: 2 > false: 4 > null: 6 > ... > > my $hash = Load $yaml; > is_deeply $hash, { true => 2, false => 4, null => 6 }, > "keys are not interpreted as booleans"; > } > >
Subject: Re: [rt.cpan.org #65662] Keys are being interpreted as booleans
Date: Sun, 13 Feb 2011 11:22:30 +1300
To: bug-YAML-LibYAML [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
On 2011.2.12 7:00 PM, Ingy dot Net via RT wrote: Show quoted text
> Unquoted values are subject to "implicit typing". That means that it is up > to the Loader to determine what they get loaded as. Numbers, boolean and > null are respected due to JSON compatibility. > > YAML::XS is arguably doing the best thing. > > However, since booleans can never be keys in JSON, it might make sense to > have the YAML loaders do make all keys strings by default.
I agree about the booleans. I can imagine inferring keys to be a string or number would be useful for strongly typed languages, so I'd have a weak preference to leave that in. Show quoted text
> I'll gladly take a patch to this effect, or possibly get a chance to look at > it next week.
I could try to slop a patch together in C. I can't see how load_scalar() can know if it's looking at a key or a value. -- 170. Not allowed to "defect" to OPFOR during training missions. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/