Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Post History
Let's start with this perl at https://www.json.org/json-en.html: A number is very much like a C or Java number, except that the octal and hexadecimal formats are not used. That's an extremely imp...
Answer
#2: Post edited
by
. .
·
2020-08-22T17:38:37Z (over 3 years ago)
purge double 'signed' word
- Let's start with this perl at https://www.json.org/json-en.html:
- > A number is very much like a C or Java number, except that the octal and hexadecimal formats are not used.
That's an extremely imprecise sentence. There are no _numbers_ in C or Java. C provides `signed` and `unsigned` `short`, `int`, `long`, `long long` numeric types, and thin character types which allow some arithmetic. Java provides signed `byte`, `short`, `int` and `long` signed numeric types, wrapping classes, and a `Number` superclass.That clarified, you should stick to strings for the sake of security. That decreases the probabilities of overflowing the parser. Instead of having developers using a maybe _happy times_ parser which may possibly believe that the number will fit default numeric types, have developers retrieve a number encapsulated in a string, with no doubt the parser isn't overflowing, and then let they explicitly choose between:- * Make the wrong assumption that the number will fit the numeric type.
- * Asserting that the number fits, and fail to assert if it does not.
- * Feeding the number to a big integers parser, provided by some third party library (or your code), in the case of C; or provided by the language, in the case of Java.
- Let's start with this perl at https://www.json.org/json-en.html:
- > A number is very much like a C or Java number, except that the octal and hexadecimal formats are not used.
- That's an extremely imprecise sentence. There are no _numbers_ in C or Java. C provides `signed` and `unsigned` `short`, `int`, `long`, `long long` numeric types, and thin character types which allow some arithmetic. Java provides signed `byte`, `short`, `int` and `long` numeric types, their wrapping classes counterparts, and a `Number` superclass.
- That clarified, you should stick to strings for the sake of security. That decreases the probabilities of overflowing the parser. Instead of having developers using a maybe _happy times_ parser which may possibly believe (wrongly (or at least eventually wrongly)) that the number will fit default numeric types, have developers retrieve a number encapsulated in a string, with no doubt the parser isn't overflowing, and then let they explicitly choose between:
- * Make the wrong assumption that the number will fit the numeric type.
- * Asserting that the number fits, and fail to assert if it does not.
- * Feeding the number to a big integers parser, provided by some third party library (or your code), in the case of C; or provided by the language, in the case of Java.
#1: Initial revision
by
. .
·
2020-08-22T17:26:41Z (over 3 years ago)
Let's start with this perl at https://www.json.org/json-en.html: > A number is very much like a C or Java number, except that the octal and hexadecimal formats are not used. That's an extremely imprecise sentence. There are no _numbers_ in C or Java. C provides `signed` and `unsigned` `short`, `int`, `long`, `long long` numeric types, and thin character types which allow some arithmetic. Java provides signed `byte`, `short`, `int` and `long` signed numeric types, wrapping classes, and a `Number` superclass. That clarified, you should stick to strings for the sake of security. That decreases the probabilities of overflowing the parser. Instead of having developers using a maybe _happy times_ parser which may possibly believe that the number will fit default numeric types, have developers retrieve a number encapsulated in a string, with no doubt the parser isn't overflowing, and then let they explicitly choose between: * Make the wrong assumption that the number will fit the numeric type. * Asserting that the number fits, and fail to assert if it does not. * Feeding the number to a big integers parser, provided by some third party library (or your code), in the case of C; or provided by the language, in the case of Java.