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 <erig...@google.com> wrote:

> On Wed, Jan 28, 2015 at 5:44 AM, Andreas Rossberg <rossb...@google.com>
> wrote:
>
>> On 28 January 2015 at 13:14, Claude Pache <claude.pa...@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.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
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to