Comment

Comment on Evil

no doesn’t become false, it becomes Norway, and when converted to a boolean, Norway is true. The reason’s because one on YAML’s native types is an ISO country code enum, and if you tell a compliant YAML implementation to load a file without giving it a schema, that type has higher priority than string. If you then call a function that converts from native type to string, it expands the country code to the country name, and a function that coerces to boolean makes country codes true.

The problem’s easy to avoid, though. You can just specify a schema, or use a function that grabs a string/bool directly instead of going via the assumed type first.

The real problem with YAML is how many implementations are a long way from being conformant, and load things differently to each other, but that situation’s been improving.

source

Sort:hotnew top

JackbyDev@programming.dev ⁨1⁩ ⁨day⁩ ago
Are you sure? I’ve always heard it the other way around and a quick search for "YAML norway’ gives this

The reason to why this is problematic in some cases, is “The Norway Problem” YAML has: when you abbreviate Norway to its ISO 3166-1 ALPHA-2 form NO, YAML will return false when parsing it

Also, YAML 1.2 (2009) changed the format of booleans to only be case insensitive true and false. “No” no longer is false if you’re parsing as a version 1.2 document.

source
- AnyOldName3@lemmy.world ⁨1⁩ ⁨day⁩ ago
  Yeah, looks like I’d remembered it backwards. It’s still an easily solvable problem by not using a load everything as whatever type you feel like function.
  
  source
Irelephant@lemm.ee ⁨1⁩ ⁨day⁩ ago
That is somehow so much worse

source
- JackbyDev@programming.dev ⁨1⁩ ⁨day⁩ ago
  I believe they’re getting themselves confused. no was false prior to YAML 1.2. This is known as the “Norway problem.”
  
  source