Hacker News Reader

Hacker News

Comment by arthurcolle | Hacker News Reader

Parent Full thread

arthurcolle

How can a string of "true" be treated like the boolean value of true? Makes no sense

View on HN

Have you seen what happens with YAML when you try to do something like

country: xx

... and get to Norway?

Congratulations, this is the first actual argument I've seen that has actually made me seriously consider never using YAML again.

Anything that accepts YAML will accept JSON.

I don't mean this in a "if you just swap the parser" way. I mean that in the "if you provide JSON to a program that expects YAML, it will parse it". JSON is a subset of YAML

So not only do you have a way of not using YAML, you can also force this decision onto most third-party services as well, and no-one will know the difference.

> JSON is a subset of YAML

That's false. http://p3rl.org/JSON::XS#JSON-and-YAML

That's bananas. I feel like I've actually had to occasion to put this to use.

YAML sounded like a really great idea to me, until I started actually reading about it. It's a literal minefield.

Some parsers intentionally support subsets of the spec for this reason, and there's multiple specs (like 1.2 which dropped support for things like 'no' to mean false), but that also just means you need to be 100% certain your parser is set up correctly. It's just not worth the extra headache to me.

Yep. I like that you can map the text to programmatic types using the tag system, and anchors are wonderful if not a bit clumsy, but the rest of the standard leaving 10 ways to do 1 thing is just too messy for me.

The only thing this should tell you is that unquoted string literals are dangerous in yml.

And because they are dangerous in yaml, the format in itself is dangerous to use. That's why any sane person should seriously consider whether using the format makes sense.

I didn't like YAML from day 1, for this and many other reasons. I never understood why it caught fire like it did.

TOML seems to be catching steam. Would you say that’sa better alternative?

> TOML seems to be catching steam.

I am convinced that TOML is the _only_ reasonable configuration format, but very few seem to be swayed.

JSON and YAML are really not made for humans. Configuration must always be a hash. Configuration must allow for expository organization of the content to help humans understand what they are editing (comments, whitespace, section headings are very helpful). Parsing configuration should not result in unexpected code execution.

TOML satisfies those criteria.

I would love to see widespread adoption, but people still seem convinced that storing configuration in JSON is human friendly.

YAML is clearly made for humans.

It's just that it's badly made for humans, in that it tries to be too helpful, leading to the various footguns scattered around the format.

TOML can be a bit verbose, especially if you have a case where your keys are more like sentences than they are like symbols. But there are no surprises, and it's quite pleasant to write by hand. I agree that it should be the first choice.

> YAML is clearly made for humans.

A format that allows references to other sections is not a configuration language that is usable by humans.

I understand the people who created it thought it would be usable by humans, but clearly it is too complicated for anyone to be able to understand a YAML file that is bigger than a dozen or so lines.

My personal favourites for humans are HCLv2 and its close cousin UCL (from FreeBSD).

HCL suffers from only having a reasonable implementation in Go, however.

I've not encountered this format before, it looks really interesting, certainly much more human friendly than JSON. Thanks for sharing.

I still don't really like it, but I've since used it for adding I18n translations in rails and I can't think of a better alternative there.

It sounds like you might have a hard time selecting technologies to use of this kind of thing is a no-go for you.

There's a bunch of others to consider on noyaml.com

You eliminate the risk and get to keep using it when you restrict yourself to never write YAML by hand. A YAML serialiser will not make the mistake.

I only found out about this in the past few days, and now it keeps me up at night.

This example might be a bit clearer as:

    country_code: NO

Huh. TIL, thanks! https://yaml.org/type/bool.html

I wonder how many Norwegians have encountered an instance of their country being rendered as "False".

I have yet to encounter this.

Norway is the opposite of Ontario, right?

In the context of YAML, the opposite is Yemen.

shakes fist at cloud

What’s the point in supporting so many ways of saying true and false?

Welcome to the wondrous world of dynamically typed languages like PHP and Ruby that are common in backend development.

True as you know it can by any of true, “true”, 1, “1”, >0 and most likely more.

All inputs in PHP start as strings because you can't tell for certain if a form input was supposed to be 1 or "1", so the language opts to not convert until you trigger it somehow. Combined with PDO for parametrized database queries, if this is PHP this error still should not happen.

Not Ruby, but Rails.

And there, it is handled by a clear and dedicated layer: ActiveModel::Type::Boolean.new.cast(value)

The only thing you can complain about is that Rails loves implicit magic, which will call this layer for you. Without you needing to set it up, or call it yourself. Many people love this about Rails. (I prefer explicitness over magic.)

Once you learn rails well enough it all becomes explicit because you can simply read the source code.

Explicit, for me, means that I determine in the model the `published_at` is a DateTime. Not merely in the DB, and never magically derived from the name (_at=datetime, _on=date). But explicitely defined. E.g. `attribute(:published_at, DateTime, default: ->{DateTime.now})`

Rails does not do this entirely "magic", though: it derives it from the database.

And true: you can follow the logic along: the magic can be researched easily. But still: I really prefer a system in which I write all that boilerplace (my IDE/vim can do this for me really well) instead of relying on convention, heuristics and magic.

Python has dynamic types but stronger typing, e.g. Can't do `a + b` if `a` is a string and `b` is a number.

Ruby is very simple. Only false and nil is falsy.

irb(main):001:0> true=="true" => false

My guess is there is something "stringly typed" somewhere in the system.

A sibling comment mentions Swift, but I doubt all components of iCloud are written in it.

Swift has "stringly-typed" enumerations (enumerations with backing "raw values" of string type), but it does not treat the enumerations as equal to the strings. Explicit conversion is required.

https://docs.swift.org/swift-book/LanguageGuide/Enumerations...

      1> let _: Bool = "true"
    error: repl.swift:1:15: error: cannot convert value of type 'String' to specified type 'Bool'
    let _: Bool = "true"
                  ^~~~~~

I don't think I'd consider it stringly-typed then. To me, stringly-typed means the type system treats strings and non-strings as convertible to each other implicitly. Strings backing enums seems more like an implementation detail and not a type system feature.

I see what you're saying, but it's not 100% an implementation detail. The raw values are accessible through the `rawValue` property, which can be useful for serialization, for example. (That could of course be abused to create bugs like the one here.)

The reason I say Swift "has" stringly-typed enums is that Objective-C has them (typedefs of NSString where the values are actually strings, and are of course implicitly convertible), and Swift imports them as enums with string-typed raw values.

Anyway, I mostly just meant to suggest that this particular iCloud bug is probably not Swift-related.

I'm pretty sure Apple uses Java for their backend services

Googling the beginning of the error message, "Type error: cannot set value", suggests it's coming from JavaScript code.

Js doesn't really care about types, and doesn't seem to convert a string "true" into a boolean true:

    > temp0.innerHTML = true // no error
    > "true" == true
    false
    > true == "true"
    false

The javascript matches are "TypeError" not "Type error", and the more important part of those are "...of null" or "...of undefined". They refer to this:

  var foo = null;
  foo.lastName = "anything"; // TypeError, cannot set property "lastName" of null

This is probably not the cause, but XML allows using the string "true" and "false" to represent booleans. https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatype...

That’s one of the most common types of errors, it’s literally the number one risk factor according to OWASP: https://owasp.org/www-project-top-ten/

I agree. I’ve also noticed the string “[]” breaks random things recently, graphql input values etc (but not a common name thankfully).

This becomes amazingly annoying when you’re trying to deal with IPv6 addresses.

Welcome to the wonderful world of implicit/dynamic typing. ;-)

Especially if it was written in a type safe language like Swift.

Highly unlikely that Swift is being used to write any backend iCloud services at this point.

Eval is evil like that.

Reply on news.ycombinator.com