[BREAKING] 0 is converted to BigInteger rather than Int32 in v0.49

[ibiernacki]

In the latest version 0.4.9, zero ("0") are converted to BigInteger, while other integers use Int32:

Converting "0":

>> $x = "0" | ConvertFrom-Yaml
>> $x.GetType()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     True     BigInteger                               System.ValueType

Converting other numbers:

>> $x = "1" | ConvertFrom-Yaml
>> $x.GetType()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     True     Int32                               System.ValueType

Why it matters?

In our scenario, we are merging several objects and eventually serialize it as a json. There is no consistency while serializing fields, for example:

>> 0 | ConvertFrom-Yaml | ConvertTo-Json
{
  "IsPowerOfTwo": false,
  "IsZero": true,
  "IsOne": false,
  "IsEven": true,
  "Sign": 0
}

>> 1 | ConvertFrom-Yaml | ConvertTo-Json
1

[gabriel-samfira]

Hi @ibiernacki,

So, ConvertTo-Json can't serialize BigInteger. This is depressing.

We switched to BigInteger for large numbers. I never tested for 0, which for some reason is cast to BitInteger instead of int32 (something I need to fix).

I won't be able to fix this today, as I need to switch to another urgent project (wish this was opened 30 minutes earlier). AS a quick workaround you can use:

PS /> 0 | ConvertFrom-Yaml | ConvertTo-Yaml -JsonCompatible
0

I will try to push a new release in the next couple of days.

[gabriel-samfira]

Here is a more complex example:

PS /home/gabriel> Import-Module powershell-yaml              
PS /home/gabriel> $aReallyBigNumber = [System.Numerics.BigInteger]::Parse("9999999999999999999999999999999999999999999999999")
PS /home/gabriel> $toSerialize = @{"aString" = "test"; "aBigNumber" = $aReallyBigNumber}                                          
PS /home/gabriel> ConvertTo-Json $toSerialize                                           
{
  "aString": "test",
  "aBigNumber": {
    "IsPowerOfTwo": false,
    "IsZero": false,
    "IsOne": false,
    "IsEven": false,
    "Sign": 1
  }
}
PS /home/gabriel> ConvertTo-Yaml -JsonCompatible $toSerialize                           
{"aString": "test", "aBigNumber": 9999999999999999999999999999999999999999999999999}

[f-bader]

Found out the hard way as well. Just adding me to the response to get future updates

[gabriel-samfira]

Yup. The switch to BigInt was done to prevent the implicit conversion that powershell does to scientific notation, as that looses precision.

Gah. Pushing a fix soon.

Please run any test suits in your apps and let me know if anything else breaks in the current version, so I can address any lingering issues and push a new release.

[gabriel-samfira]

A fix for the case where 0 is cast as BigInt is here: #165

Note that really large numbers will still be cast as BigInteger. In such cases, if you need to serialize back to json, I recommend you use ConvertTo-Yaml -JsonCompatible, as that will generate a valid json. The only downside will be that you won't have indents in your json.

[gabriel-samfira]

Leaving open until a release is published. If you spot any other issues after running your tests, feel free to open a bug. Releasing a new version in 2 days to allow any other issues to be reported and fixed all in one release.

[gabriel-samfira]

Ouch:

PS /home/gabriel> ('9223372036854775808' | ConvertFrom-Json).GetType()      

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     True     BigInteger                               System.ValueType

PS /home/gabriel> '9223372036854775808' | ConvertFrom-Json  | ConvertTo-Json
{
  "IsPowerOfTwo": true,
  "IsZero": false,
  "IsOne": false,
  "IsEven": true,
  "Sign": 1
}

Apparently this was reported here: PowerShell/PowerShell#20989

and fixed here: PowerShell/PowerShell#21000

[gabriel-samfira]

I released a new version with a fix for this, as I really need to move to another project for a while. If anything major comes up after you folks get a chance to test. I'll try to address it.