[M3devel] TextLiteral.MaxBytes again

[Tony Hosking]

Here is a modest proposal that should resolve this issue.
Declare TextLiteral.T to have a minimal buf: ARRAY [0..0] OF Byte;
Then use UNSAFE address arithmetic to access the bytes (TextLiteral.m3 already does the bounds checks explicitly using cnt).

Updated TextLiteral.i3 and TextLiteral.m3 attached.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: TextLiteral.i3
Type: application/octet-stream
Size: 1134 bytes
Desc: not available
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130905/d9b59db4/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TextLiteral.m3
Type: application/octet-stream
Size: 2989 bytes
Desc: not available
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130905/d9b59db4/attachment-0005.obj>
-------------- next part --------------




Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Mobile +1 765 427 5484





On Sep 5, 2013, at 10:42 AM, "Rodney M. Bates" <rodney_bates at lcwb.coop> wrote:

> There is another issue here.  I want TextLiteral.MaxBytes to get a final size
> and not change.  Every time it changes, it creates compatibility problems by
> orphaning any existing pickle files and any compiled programs that write them.
> It changes the fingerprint, so a recently-compiled reading program can't find the
> type in its own list of known types.  This also affects network objects when two
> communicating programs are compiled with different TextLiteral versions.
> 
> MaxBytes' particular contribution to the type doesn't otherwise matter, because it's
> artificial, but it still undermines reading pickles.
> 
> I have been loading up the pickle reading code with hard-coded historical fingerprints
> of various older versions.  But it's a pain to keep doing, tedious to ferret out the
> values, and it still only helps those who constantly download and compile the latest
> CM3.
> 
> At some point, I am thinking of choosing some likely historical TextLiteral.T fingerprint
> and hard-coding the compiler to artificially deliver it , rather than the one computed from
> the version-of-the day of TextLiteral.  But this too would not help those who would
> rather not constantly download the latest, rebuild the compiler, then recompile their
> applications.
> 
> On 09/03/2013 01:02 AM, Jay K wrote:
>> ok, another question:
>> 
>> 
>> CONST
>>  (* DIV BITSIZE should not be here! *)
>>  (* MaxBytes = LAST (INTEGER) DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64); *)
>>  MaxBytes = 16_7FFFFFFF DIV BITSIZE (Byte) - 7 - 8 * ORD(BITSIZE(INTEGER) = 64);
>> 
>> TYPE
>>   T = RTHooks.TextLiteral;
>> REVEAL
>>   T = TEXT BRANDED "TextLiteral.T" OBJECT
>>     cnt : INTEGER;
>>     buf : ARRAY [0..MaxBytes - 1] OF Byte;
>>   OVERRIDES ...
>> 
>> 
>> T is a reference type.
>> Is there a way to state this with no limit?
>> 
>> 
>> Isn't it already unsafe?
>> You know -- the array is usually smaller and the compiler is only going to check against this large size.
>> 
>> 
>>  - Jay
>