[bug] Leading zero in string fields interpreted as octal

[JelmerT]

Issue:
when using an int with a leading zero in the mpn or any other field, the number gets interpreted as an octal number.

How to reproduce:
This

  X2:
    type: "Picoblade 1.25MM \nOr Equivalent"
    pn: 0510210600
    mpn: 0510210600
    manufacturer: MOLEX
    subtype: female
    pins: [6,5,4,3,2,1]
    pinlabels: [+5v, Data Request, Data GND, NC, Data, Power GND]

compiles into this

Note the different product numbers.

This is an issue that's very easy to miss and could result in the wrong part being selected.

Fixes could be to allow int and str for these fields, and make sure they get interpreted correctly, or to throw an error if an int is input where a str is expected.

[kvid]

Thank you for reporting this. It seems to be how the current YAML parser is intended to work. It might change in the future, e.g. if deciding to use a parser supporting YAML version 1.2 - where the octal number prefix is changed to '0o'.

To avoid such problems, I recommend quoting strings that might be interpreted the wrong way, e.g. pn: '0510210600' or mpn: "0510210600".

[JelmerT]

May I suggest putting a note about this in the docs in the mean while?

[formatc1702]

Parsing a leading 0 as octal is pretty unintuitive IMHO, and manufacturers are notorious for having leading 0s in their part numbers, so I've opened #223 to discuss switching to a different YAML parser. I'd much rather have an intuitive solution (soon) than having to point to the docs and requiring quotation marks... Thanks for the heads up!