Hello. I think I found an issue with my pull request #39: I think that the empty string should be quoted, because otherwise, it will be parsed as a Unit. Thanks.

Hi :)

my example yaml:

0:
    important: true

1:
    important: false

main:
pub use modules::config;
fn main() {
    // TODO add via argument
    static CONFIG_STRING: &'static str = "etc/GUS.yml";
    let cfg = config::get_yaml_config(&CONFIG_STRING);

    // Let's runtime!
    runtime::RTM { config: &cfg }.run();    
}

config:
pub fn get_yaml_config(config_file: &str) -> Array {
    let path_to_file = Path::new(&config_file);
    let display = path_to_file.display();
    let mut fd = match File::open(&path_to_file) {
        Err(why) => panic!("couldn't open {}: {}", display, why.description()),
        Ok(file) => file
    };

    let mut content = String::new();
    match fd.read_to_string(&mut content) {
        Err(why) => panic!("couldn't read {}: {}", display, why.description()),
        Ok(_) => println!(""),
    };
    // return Array
    yaml_loader::load_from_str(&content).unwrap()
}

runtime:
pub use config;
use yaml_rust::yaml::Array;

#[derive(Debug)]
pub struct RTM<'a> {
    pub config: &'a Array
}

impl<'a> RTM<'a> {
    pub fn run(&self) {
        let gus_config = &self.config[0];
        println!("{:?}", gus_config[0]);
    }
}

Then get an error when I try to acess index 0:

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /buildslave/rust-buildbot/slave/stable-dist-rustc-linux/build/src/libcore/option.rs:323
note: Run with `RUST_BACKTRACE=1` for a backtrace.

Regards Gino

Thank you for writing a great YAML parser for Rust! I'm working on several programs which make heavy use of it.

I ran into a rather tricky problem this morning, when I tried to use two Rust crates in the same program. And I'd love to get your feedback on it:

• serde_yaml 0.5.0 requires that yaml-rust be configured with the feature preserve_order enabled.
• clap requires that yaml-rust be configured with preserve_order disabled.

Trying to use both crates in the same program will turn on preserve_order and break clap:

error[E0308]: if and else have incompatible types
   --> /home/emk/.cargo/registry/src/github.com-1ecc6299db9ec823/clap-2.18.0/src/args/group.rs:463:30
    |
463 |         let group_settings = if b.len() == 1 {
    |                              ^ expected struct `linked_hash_map::LinkedHashMap`, found struct `std::collections::BTreeMap`
    |
    = note: expected type `&linked_hash_map::LinkedHashMap<yaml_rust::Yaml, yaml_rust::Yaml>`
    = note:    found type `&'a std::collections::BTreeMap<yaml_rust::Yaml, yaml_rust::Yaml>

I asked the Cargo maintainers on IRC if there was any workaround for this, and they said:

<sfackler> ekidd: features are normally supposed to be purely additive because of problems like these
<sfackler> seems like something you'd have to bug the yaml-rust people about unfortunately

As I understand it, this means that if a feature is enabled, it shouldn't change any of the existing APIs of the crate. I'm not sure what the best solution is here.

I've filed related issues against the affected projects: https://github.com/kbknapp/clap-rs/issues/747 https://github.com/dtolnay/serde-yaml/issues/33

Thank you for any suggestions you can provide, and for writing a great YAML parser for Rust!

Hi,

the latest crates.io release is 8 months old. There're bugfixes (especially in the emitter) that are awesome. It would be great to have a new release with those fixes.

Thanks

Cherry-picked from https://github.com/palfrey/yaml-rust/pull/1:

Currently, heavily nested arrays or hashes used as keys of hashes (such as a hash<hash<array<_>, _>, _>) were either illegally written, or caused an error when attempted to be emitted. This fixes that situation by using the ? ... : YAML mapping form (as shown in example 2.11 here), which is more amenable to writing complex keys.

If the key of a hashmap is not complex (i.e. a number, string, etc), then the emitting code is unchanged.

Is this still the case, that this library is not ready for accepting untrusted output?

If so, how much am I risking here? Remote code execution, or a panic? If a panic, that in my application, I could probably live with it, at least temporarily.

Currently, the library incorrectly doesn't add quotes to strings, which will be interpreted as booleans: https://github.com/chyh1990/yaml-rust/blob/bbe06964006ef8c12cd1f08b00bd6a95a0e752d1/src/emitter.rs#L270-L271

Specs describes many other possiblities: http://yaml.org/type/bool.html

Personally, I encounter this bug with string TRUE in https://github.com/InQuicker/ktmpl/ which produced such value without qutes and kubernetes doesn't accept that value.

Hey, I was playing around with the YamlEmitter and noticed that it did not yet support complex hashmap key and instead returned an Error. With this PR I'm trying to introduce this functionality, please give it a try.

Thank you very much

Hey there, I implemented Yaml::to_string() and From<&Yaml> for String. I know it's a bit of a duplication of YamlEmitter, but I found this more accessible.

cheers

Hey, I just noticed that alias were intended but are not fully implemented. I could use this feature. Could you finish it or perhaps give me some hints so I can do it? Thank you.

I noticed while debugging some Rust apps this crate was throwing uninitialized value warnings in valgrind. I don't know if this is real UB or bogus warnings, just reporting it to be safe.

Rust version: rustc 1.43.1 (8d69840ab 2020-05-04)

Test case: https://gist.github.com/xTibor/8858ecf5cbd276bc8673267ee5d324ac

Valgrind logs:

==11197== Conditional jump or move depends on uninitialised value(s)
==11197==    at 0x1252C3: yaml_rust::parser::Parser<T>::parser_process_directives (in /home/user/git/yaml-rust/target/release/examples/overrides)
==11197==    by 0x1250F3: yaml_rust::parser::Parser<T>::document_start (in /home/user/git/yaml-rust/target/release/examples/overrides)
==11197==    by 0x122112: yaml_rust::parser::Parser<T>::next (in /home/user/git/yaml-rust/target/release/examples/overrides)
==11197==    by 0x12360A: yaml_rust::parser::Parser<T>::load (in /home/user/git/yaml-rust/target/release/examples/overrides)
==11197==    by 0x11E247: yaml_rust::yaml::YamlLoader::load_from_str (in /home/user/git/yaml-rust/target/release/examples/overrides)
==11197==    by 0x10D892: overrides::main (in /home/user/git/yaml-rust/target/release/examples/overrides)
==11197==    by 0x10D4B2: std::rt::lang_start::{{closure}} (in /home/user/git/yaml-rust/target/release/examples/overrides)
==11197==    by 0x1362B2: {{closure}} (rt.rs:52)
==11197==    by 0x1362B2: std::panicking::try::do_call (panicking.rs:303)
==11197==    by 0x137FF6: __rust_maybe_catch_panic (lib.rs:86)
==11197==    by 0x136CBB: try<i32,closure-0> (panicking.rs:281)
==11197==    by 0x136CBB: catch_unwind<closure-0,i32> (panic.rs:394)
==11197==    by 0x136CBB: std::rt::lang_start_internal (rt.rs:51)
==11197==    by 0x10DA31: main (in /home/user/git/yaml-rust/target/release/examples/overrides)
==11197==  Uninitialised value was created by a stack allocation
==11197==    at 0x125250: yaml_rust::parser::Parser<T>::parser_process_directives (in /home/user/git/yaml-rust/target/release/examples/overrides)

Greetings,

Thank you for yaml-rust!

I see in the docs:

assert_eq!(doc["foo"][0].as_str().unwrap(), "list1");

I would like to do something like:

let key = "[foo][0]";
assert_eq!(doc.dynamic_lookup(key).unwrap(), "list1");

Do you know if it is possible with yaml-rust?

Thanks!

Hi and thanks for this very useful crate.

I am considering using this crate to use YAML instead of pure JSON for the configuration files of one of my projects, but am not sure what to think about the use of unsafe-libyaml... Safety is a big concern for us and this effectively introduces a bunch of unsafe code responsible for parsing arbitrary input.

Looking at the history I see that yaml-rust was used previously, but seems to have been abandoned in favor of unsafe-libyaml due to lack of maintenance. That's unfortunate but the decision is understandable.

Are there other alternatives that could be used to parse YAML? Or are my concerns about unsafe-libyaml unwarranted?

@chyh1990 Would you like to invite other maintainers to help here or relinquish your cargo publishing area to a developer who would like to step up and maintain the package in their fork?

Hi, I would like to help integrate this project into oss-fuzz.

• As an initial step for integration I have created this PR: https://github.com/google/oss-fuzz/pull/8250, it contains necessary logic from an OSS-Fuzz perspective to integrate yaml-rust. This includes developing initial fuzzers as well as integrating into OSS-Fuzz.

• Essentially, OSS-Fuzz is a free service run by Google that performs continuous fuzzing of important open source projects.

• If you would like to integrate, could I please have an email(s), it must be associated with a Google account like gmail (why?). by doing that, the provided email(s) will get access to the data produced by OSS-Fuzz, such as bug reports, coverage reports and more stats.

• Notice the email(s) affiliated with the project will be public in the OSS-Fuzz repo, as they will be part of a configuration file.

The official YAML test suite (https://github.com/yaml/yaml-test-suite). Requires the submodule to be checked out.

This is a draft PR because there's quite a number of failures. At the moment I'm seeing 62 unexpected errors (and 19 more errors where yaml-rust Event / Parser / EventReceiver API does not provide enough information about the document). I can mark the other errors as expected errors for now, but want to look at them first to check whether they're yaml-rust errors or some mistakes in this test harness.