Skip to content
This repository was archived by the owner on Apr 4, 2025. It is now read-only.

[BUG-6466] Numbers expressed in scientific notation and include a plus sign in the exponent are not parsed as json numbers by LSL #14324

Open
1 task
sl-service-account opened this issue Jun 24, 2014 · 6 comments
Open
1 task

[BUG-6466] Numbers expressed in scientific notation and include a plus sign in the exponent are not parsed as json numbers by LSL #14324

sl-service-account opened this issue Jun 24, 2014 · 6 comments
Labels
project:BUG

Comments

@sl-service-account
Copy link

sl-service-account commented Jun 24, 2014 •
edited by sl-issues-importer bot
Loading

Steps to Reproduce

Create this script:

default
{
    state_entry()
    {
        string value = "1.0e+1";
        llOwnerSay("\n" + (string)(llJsonValueType(value, []) == JSON_INVALID)
            + "\n" + (string)(llJsonGetValue(value, []) == JSON_INVALID)
            + "\n" + llJsonSetValue("", [], value)
            + "\n" + (string)llJson2List("["+value+"]"));
    }
}

Then replace 1.0e+1 with 1.0e1 and rerun it again.

Actual Behavior

Output with 1.0e+1 is:

1
1
"1.0e+1"
1.0e+1

And with 1.0e1 is:

0
0
1.0e1
10.000000

Expected Behavior

Output with 1.0e+1 should be instead:

0
0
1.0e+1
10.000000

Output with 1.0e1 is correct.

Other information

A + sign in an exponent is perfectly valid JSON as per http://json.org/number.gif

Functions affected are the four in the script: llJsonValueType, llJsonGetValue, llJsonSetValue, llJson2List.

llList2Json is not affected because of the weird behavior that BUG-6284 claims to be valid.

Links

Related

Original Jira Fields
Field Value
Issue BUG-6466
Summary Numbers expressed in scientific notation and include a plus sign in the exponent are not parsed as json numbers by LSL
Type Bug
Priority Unset
Status Accepted
Resolution Accepted
Reporter Sei Lisa (sei.lisa)
Created at 2014-06-24T12:53:24Z
Updated at 2014-07-11T22:25:16Z 
{
  'Business Unit': ['Platform'],
  'Date of First Response': '2014-06-24T09:29:26.119-0500',
  "Is there anything you'd like to add?": 'A + sign in an exponent is perfectly valid JSON as per http://json.org/number.gif\r\n\r\nFunctions affected are the four in the script: llJsonValueType, llJsonGetValue, llJsonSetValue, llJson2List.\r\n\r\nllList2Json is not affected because of the weird behavior that BUG-6284 claims to be valid.\r\n',
  'System': 'SL Simulator',
  'Target Viewer Version': 'viewer-development',
  'What just happened?': 'Output with 1.0e+1 is:\r\n{code}\r\n1\r\n1\r\n"1.0e+1"\r\n1.0e+1\r\n{code}\r\n\r\nAnd with 1.0e1 is:\r\n{code}\r\n0\r\n0\r\n1.0e1\r\n10.000000\r\n{code}\r\n',
  'What were you doing when it happened?': 'Create this script:\r\n\r\n{code}\r\ndefault\r\n{\r\n    state_entry()\r\n    {\r\n        string value = "1.0e+1";\r\n        llOwnerSay("\\n" + (string)(llJsonValueType(value, []) == JSON_INVALID)\r\n            + "\\n" + (string)(llJsonGetValue(value, []) == JSON_INVALID)\r\n            + "\\n" + llJsonSetValue("", [], value)\r\n            + "\\n" + (string)llJson2List("["+value+"]"));\r\n    }\r\n}\r\n{code}\r\n\r\nThen replace 1.0e+1 with 1.0e1 and rerun it again.\r\n',
  'What were you expecting to happen instead?': 'Output with 1.0e+1 should be instead:\r\n\r\n{code}\r\n0\r\n0\r\n1.0e+1\r\n10.000000\r\n{code}\r\n\r\nOutput with 1.0e1 is correct.\r\n',
  'Where': 'Anywhere',
}
@sl-service-account
Copy link
Author

Maestro Linden commented at 2014-06-24T14:29:26Z

Hi Sei, thanks for the report. I can reproduce this; '1.0e1' and '1.0e-1' are correctly parsed as json numbers, but as you said, '1.0e+1' is not. You're right, according to RFC-4627 section 2.4, an optional plus sign in the exponent should be legal:
http://www.ietf.org/rfc/rfc4627.txt

@sl-service-account
Copy link
Author

Sei Lisa commented at 2014-06-24T14:51:39Z

Exponents with positive sign are often generated by JSON processors. For example, this PHP script:

<?php
echo json_encode(1e14);

outputs '1.0e+14' which is not parse-able by the above functions.

The particular case of llJson2List can probably be better appreciated with this script:

default
{
    state_entry()
    {
        llOwnerSay(llList2CSV([
            llGetListEntryType(llJson2List("[1.0e+20]"), 0),
            llGetListEntryType(llJson2List("[1.0e20]"), 0)
        ]));
    }
}

which outputs '3, 2' (i.e. TYPE_STRING, TYPE_NUMBER) instead of the expected '2, 2' (i.e. TYPE_NUMBER, TYPE_NUMBER).

@sl-service-account
Copy link
Author

Sei Lisa commented at 2014-06-24T15:17:50Z, updated at 2014-06-24T15:18:37Z

dup

@sl-service-account
Copy link
Author

Sei Lisa commented at 2014-06-24T15:18:07Z, updated at 2014-06-24T15:18:50Z

dup

@sl-service-account
Copy link
Author

Sei Lisa commented at 2014-06-26T21:36:05Z

Given that the number parsing routines are being improved, could it be added to the tests to reject a dot in the exponent part? That is currently accepted, e.g. 1e2.3 is currently valid, and it obviously shouldn't.

@sl-service-account
Copy link
Author

Sei Lisa commented at 2014-07-11T21:15:04Z, updated at 2014-07-11T21:53:07Z

I've tested the fix. It broke the case of e.g. "0e0" which is a valid JSON number but not accepted by LSL (it was before). EDIT: I'll post it as a new issue.

@sl-issues-importer sl-issues-importer bot mentioned this issue Feb 14, 2024
Open
1 task
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
project:BUG
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@sl-service-account