[M3devel] TextLiteral.MaxBytes -- use LONGINT or Target.Int more?

[Rodney M. Bates]

On 09/03/2013 12:50 PM, Jay K wrote:
> I think it isn't just TextLiteral.MaxBytes.
>
>
> How do I declare an unbouned-ly sized array?

You use an open array.  Then the compiler arranges to store its bound at runtime,
using that instead of a static constant when generating bounds checks.

In order to avoid big messes in both language definition and implementation,
you can create a "ground" open array value only by allocating it in the heap.
You can also, in effect, convert a fixed array value (created any way you like)
by passing it to a formal of open array type or applying SUBARRAY to it with
non-static length.

The whole TextLiteral thing is a low-level implementation thing to allow the
compiler to construct it statically, yet avoid having to always copy it into
the traced heap the first thing at runtime.  I haven't looked, but I would bet
PM3 always copies a text literal into a heap object before creating a traced
reference value pointing to it.

Yes, it's unsafe in the sense that the usual array bounds mechanism is just
circumvented by making it a fixed array with much larger bound than reality.
The code in TextLiteral takes care of enforcing the bounds, instead of the
usual compiler-generated mechanism.

> At the end of a record?

The language does not allow this.  It has to be an autonomous object.  I have
a use-case that would save a lot of space if you could do this.  There is big
space overhead in separating it into a separate object, which can matter if
the average size of the arrays is small.

I have often thought about the implications of allowing it.  I think the effects
on the language would be dire, and would also require a lot of implementation
work, including lots of GC additions.  This is the same ol' tradeoff.  Highly
flexible mechanisms are less efficient.

> Doesn't matter?
>


>
> For TextLiteral.MaxBytes, are you ok then with a 512MB limit, even for 64bit?
>
>

For legitimate uses, this limit is quite enough.  Right off hand, I doubt the old
crack of, e.g., entering 4K character passwords, user names, etc., can be used
here, because all text values, TextLiteral included, are compiled as immutable
objects.  Input values would never be stored into an existing text literal.
Even if they were, the TextLiteral library code would be checking bounds at
runtime.  In at least some targets, these are also stored in readonly segments as well.

>   - Jay
>
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 --
> From: hosking at cs.purdue.edu
> Date: Tue, 3 Sep 2013 13:00:08 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] TextLiteral.MaxBytes -- use LONGINT or Target.Int more?
>
> Yes, I want to avoid use of LONGINT in the compiler proper.
> If you want to talk about target sized integer values in the front-end then yes, Target.Int is what you want, I suppose.
> But I still don’t understand the precise use-case that you are proposing.
> In the case of TextLiteral.MaxBytes why would 512 Mb ever be too small?
> I cannot imaging a text literal that big, ever.
>
>
>
> Antony Hosking|Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Mobile+1 765 427 5484
>
>
>
>
>