Maximum String length
Le 28 janv. 2015 à 09:58, Jordan Harband <ljharb at gmail.com> a écrit :
To me, "finite" here means
Number.MAX_VALUE- ie, the highest number I can get before I reach Infinity. An alternative reading is "any number greater than zero that's not Infinity" - but at that point an implementation conforms if it's max length is 1, which obviously would be silly.
To me, "finite" is just to be taken in the common mathematical sense of the term; in particular you could have theoretically a string of length 10^10000. But yes, it would be reasonable to restrict oneself to strings of length at most 2^52, so that string.length could always return an exact answer.
On 28 January 2015 at 13:14, Claude Pache <claude.pache at gmail.com> wrote:
To me, "finite" is just to be taken in the common mathematical sense of the term; in particular you could have theoretically a string of length 10^10000. But yes, it would be reasonable to restrict oneself to strings of length at most 2^52, so that
string.lengthcould always return an exact answer.
To me it would be reasonable to restrict oneself to much shorter strings, since no existing machine has the memory to represent a string of length 2^52, nor will any in the foreseeable future. ;)
VMs can always run into out-of-memory conditions. In general, there is no way to predict those. Even strings with less then the hard-coded length limit might cause you to go OOM. So providing reflection on a constant like that might do little but giving a false sense of safety.
On Wed, Jan 28, 2015 at 5:44 AM, Andreas Rossberg <rossberg at google.com> wrote:
To me it would be reasonable to restrict oneself to much shorter strings, since no existing machine has the memory to represent a string of length 2^52, nor will any in the foreseeable future. ;)
That's just four petabytes. If present trends...
VMs can always run into out-of-memory conditions. In general, there is no way to predict those. Even strings with less then the hard-coded length limit might cause you to go OOM. So providing reflection on a constant like that might do little but giving a false sense of safety.
Yes, OOM is always possible earlier and we can't set any limits on that. I agree that we shouldn't provide anything like String.MAX_LENGTH. But I also don't see how we could pleasantly support strings above 2^53. Array indexes are limited to 2^31 or so, and many integer operations truncate to that (<<,|), and strings support [] indexing, so it may make sense to agree on one of those as an upper bound -- you may not support strings longer than that.
Strings can't possibly have a length larger than Number.MAX_SAFE_INTEGER - otherwise, you'd be able to have a string whose length is not a number representable in JavaScript. So, at the least, I think it would make sense to define a maximum string length as Number.MAX_SAFE_INTEGER, even if that provides no guarantees that strings of that length will work (ie, OOM errors etc are fine), whether it's exposed on String or not.
It might also be nice if the spec included a non-normative note that suggested a lower bound for a maximum string length (where strings are guaranteed to work), so that at least there's a guideline.
Thoughts?
From: es-discuss [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Jordan Harband
Strings can't possibly have a length larger than Number.MAX_SAFE_INTEGER - otherwise, you'd be able to have a string whose length is not a number representable in JavaScript.
So? That's a bit inconvenient, but no reason to argue that such a string can't exist.
I suppose we could change the spec, but people.mozilla.org/~jorendorff/es6-draft.html#sec-ecmascript-language-types-string-type requires that "The length of a String is the number of elements (i.e., 16-bit values) within it." - if the number can't be represented, then it seems that requirement can't be satisfied. I'm sure one can come up with a counterintuitive reading of the spec, but is that a realistic interpretation of it?
Le 29 janv. 2015 à 01:49, Jordan Harband <ljharb at gmail.com> a écrit :
I suppose we could change the spec, but people.mozilla.org/~jorendorff/es6-draft.html#sec-ecmascript-language-types-string-type requires that "The length of a String is the number of elements (i.e., 16-bit values) within it." - if the number can't be represented, then it seems that requirement can't be satisfied. I'm sure one can come up with a counterintuitive reading of the spec, but is that a realistic interpretation of it?
It's not a requirement, it's a definition. But more on the point, the length of a String is simply a nonnegative integer, not a Number value representing such a integer. Not to be confused with the value of the "length" property of that String, which is necessarily a Number value.
Typically, implementation-specific things aren't specified in the spec (like Math precision, etc) - although usually when it's implementation-specific, it's explicitly noted as such ( people.mozilla.org/~jorendorff/es6-draft.html#sec-date.parse , people.mozilla.org/~jorendorff/es6-draft.html#sec-math.hypot , people.mozilla.org/~jorendorff/es6-draft.html#sec-ecmascript-language-types-number-type , people.mozilla.org/~jorendorff/es6-draft.html#sec-object.keys , etc)
Strings are only defined in ES6 as a "primitive value that is a finite ordered sequence of zero or more 16-bit unsigned integer" ( people.mozilla.org/~jorendorff/es6-draft.html#sec-terms-and-definitions-string-value ) and are not noted as having any implementation-specific or implementation-dependent qualities.
To me, "finite" here means
Number.MAX_VALUE- ie, the highest number I can get before I reach Infinity. An alternative reading is "any number greater than zero that's not Infinity" - but at that point an implementation conforms if it's max length is 1, which obviously would be silly.However, Chrome 40 and Opera 26-27 have a limit of
0xFFFFFF0(2**28 - 2**4), Firefox 35 and IE 9-11 all have a limit of0xFFFFFFF(2**28 - 1), and Safari 8 has0x7FFFFFFF(2**31 - 1). There's many more browsers I haven't tested of course but it'd be interesting to know how wide these numbers deviate.Number.MAX_VALUE, asString.MAX_LENGTH? This will help, for example, myString#repeatpolyfill throw an earlierRangeErrorrather than having to try to build a string of that length.