Maximum String length

[Jordan Harband]

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 ( https://people.mozilla.org/~jorendorff/es6-draft.html#sec-date.parse , https://people.mozilla.org/~jorendorff/es6-draft.html#sec-math.hypot , https://people.mozilla.org/~jorendorff/es6-draft.html#sec-ecmascript-language-types-number-type , https://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" ( https://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 of `0xFFFFFFF` (`2**28 - 1`), and Safari 8 has `0x7FFFFFFF` (`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.

1) Should an engine's max string length be exposed, like `Number.MAX_VALUE`, as `String.MAX_LENGTH`? This will help, for example, my `String#repeat` polyfill throw an earlier `RangeError` rather than having to try to build a string of that length.

2) Should the spec require a minimum maximum string length, or at least be more specific in how it defines "finite"?

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

[Claude Pache]

Le 28 janv. 2015 à 09:58, Jordan Harband <[hidden email]> a écrit :

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 ( https://people.mozilla.org/~jorendorff/es6-draft.html#sec-date.parse , https://people.mozilla.org/~jorendorff/es6-draft.html#sec-math.hypot , https://people.mozilla.org/~jorendorff/es6-draft.html#sec-ecmascript-language-types-number-type , https://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" ( https://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.

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.

—Claude

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 of `0xFFFFFFF` (`2**28 - 1`), and Safari 8 has `0x7FFFFFFF` (`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.

1) Should an engine's max string length be exposed, like `Number.MAX_VALUE`, as `String.MAX_LENGTH`? This will help, for example, my `String#repeat` polyfill throw an earlier `RangeError` rather than having to try to build a string of that length.

2) Should the spec require a minimum maximum string length, or at least be more specific in how it defines "finite"?

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

[Andreas Rossberg-4]

On 28 January 2015 at 13:14, Claude Pache <[hidden email]> 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.length` could 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.

/Andreas

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

[Mark S. Miller-2]

On Wed, Jan 28, 2015 at 5:44 AM, Andreas Rossberg <[hidden email]> wrote:

On 28 January 2015 at 13:14, Claude Pache <[hidden email]> 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.length` could 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. ;)

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.

--

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

[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, 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?

On Wed, Jan 28, 2015 at 6:53 AM, Mark S. Miller <[hidden email]> wrote:

On Wed, Jan 28, 2015 at 5:44 AM, Andreas Rossberg <[hidden email]> wrote:

On 28 January 2015 at 13:14, Claude Pache <[hidden email]> 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.length` could 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. ;)

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.

--

    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

[Domenic Denicola]

From: es-discuss [mailto:[hidden email]] 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.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

[Jordan Harband]

I suppose we could change the spec, but https://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?

On Wed, Jan 28, 2015 at 4:37 PM, Domenic Denicola <[hidden email]> wrote:

From: es-discuss [mailto:[hidden email]] 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.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

[Claude Pache]

Le 29 janv. 2015 à 01:49, Jordan Harband <[hidden email]> a écrit :

I suppose we could change the spec, but https://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.

—Claude 

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss