jq stops printing strings converted to number after first conversion fails

[thalman]

Jq stops converting strings to numbers on first conversion failure.

To Reproduce
jq '.[]| tonumber?' <<< '["1", "invalid2", "3"]'

Expected behavior
Expected output (works with 1.5):
1
3

jq 1.6 output ("3" is missing)
1

Environment:

• OS and Version: Linux Fedora 35 (but I believe it is on all platforms)
• jq version 1.6

Additional context
Only string conversion is affected. The iteration actually continues and if there are following numbers, they are printed

jq '.[]| tonumber?' <<< '["1", "invalid2", "3", 4]'
1
4
^^^ 3 is missing, but 4 is printed

[thalman]

PR #2400

[thirumalaicb]

Hi @thalman,

I got to know about jq only a few days ago and I am no expert. I am using MacOS Big Sur 11.5.2 and jq version 1.6. But, I don't seem to encounter this issue. Please see below screenshot.

[thalman]

Hello @thirumalaicb

Thanks for pointing this out - a bit more digging shows that there is also configure option that has an effect on this. If the jq 1.6 is configured with

./configure --disable-decnum

then it works well on my Fedora. Using

./configure --enable-decnum # this is default

causes the problem. Is that option used in your case?

Regards
Tomáš

[ChristianCiach]

This is probably related to #2403. This means it doesn't only affect tonumber but also fromjson and probably some other functions.

[itchyny]

I confirmed this is a regression after 1.6. More understandable example is

 $ jq '[.[] | try tonumber catch .]' <<< '["1", "invalid", "3", 4]'
[
  1,
  "Invalid numeric literal at EOF at line 1, column 7 (while parsing 'invalid')",
  "Invalid numeric literal at EOF at line 1, column 1 (while parsing '3')",
  4
]
 $ jq --version
jq-master-80052e5

But it should be

 $ jq-1.6 '[.[] | try tonumber catch .]' <<< '["1", "invalid", "3", 4]'
[
  1,
  "Invalid numeric literal at EOF at line 1, column 7 (while parsing 'invalid')",
  3,
  4
]
 $ jq-1.6 --version
jq-1.6

[itchyny]

I was using a bit older jq and didn't read the thread carefully. This bug was indeed fixed by #2400 (c4d39c4) on May 27, 2022.