This is the planned patch to bump the image version:
F:\work\svn\oorexx\main\trunk\interpreter\classes\support>svn diff
Index: ProgramMetaData.hpp
===================================================================
--- ProgramMetaData.hpp (revision 12347)
+++ ProgramMetaData.hpp (working copy)
@@ -1,7 +1,7 @@
/*----------------------------------------------------------------------------*/
/*
*/
/* Copyright (c) 1995, 2004 IBM Corporation. All rights reserved.
*/
-/* Copyright (c) 2005-2019 Rexx Language Association. All rights reserved.
*/
+/* Copyright (c) 2005-2022 Rexx Language Association. All rights reserved.
*/
/*
*/
/* This program and the accompanying materials are made available under
*/
/* the terms of the Common Public License v1.0 which accompanies this
*/
@@ -71,7 +71,7 @@
enum
{
MAGICNUMBER = 11111, // remains constant from
release-to-release
- METAVERSION = 42 // gets updated when internal form
changes
+ METAVERSION = 43 // gets updated when internal form
changes
};
---rony
On 20.01.2022 20:13, Rony G Flatscher wrote:
>
>> Am 20.01.2022 um 19:25 schrieb Rick McGuire <object.r...@gmail.com>:
>>
>>
>> Yes they do.
> Thank you!
>
> Shouldn‘t we bump the imageversion (?) field then such that running previous
> image versions yield
> a runtime error?
>
> —-rony
>
> Rony G. Flatscher (mobil/e)
>>
>> On Thu, Jan 20, 2022 at 12:52 PM Rony G. Flatscher <rony.flatsc...@wu.ac.at
>> <mailto:rony.flatsc...@wu.ac.at>> wrote:
>>
>> At the end of November there were the following changes to
>> interpreter/classes/support/ProgramMetaData.{c|h}pp (rev 12325 and rev
>> 12327, "svn diff -r
>> PREV ProgramMetaData.*") :
>>
>> Index: ProgramMetaData.cpp
>>
>> ===================================================================
>>
>> --- ProgramMetaData.cpp (revision 12327)
>>
>> +++ ProgramMetaData.cpp (working copy)
>>
>> @@ -304,10 +304,6 @@
>>
>> data++;
>> }
>>
>> - // pass back the pointer to the metadata location, assuming for
>> now that
>> - // here is metadata.
>> - metaData = (ProgramMetaData *)data;
>> -
>> // adjust the length for everything after the shebang
>> length -= data - buffer->getData();
>>
>> @@ -314,6 +310,21 @@
>>
>> // Now check in binary form of the compiled version
>> if (length > strlen(compiledHeader) && strcmp(data,
>> compiledHeader) == 0)
>> {
>> + // the problem with having a shebang in front of the data
>> is that it opens the
>> + // possibility that the flattened program data is not
>> aligned on an object grain
>> + // boundary. This can either cause invalid objects to
>> created on the heap or even
>> + // result in data exceptions if the fields are not aligned
>> on a proper word boundary.
>> + // If this is anywhere other than the front of the buffer,
>> we need to shift it to
>> + // the front.
>> +
>> + // the returned metadata will be at the beginning
>> + metaData = (ProgramMetaData *)buffer->getData();
>> +
>> + // once we've shifted it
>> + if (data != buffer->getData())
>> + {
>> + memmove((void *)buffer->getData(), (void *)data, length);
>> + }
>> return true;
>> }
>>
>> @@ -327,8 +338,13 @@
>>
>>
>> size_t decodedLength;
>>
>> + // Note that we are decoding to the beginning of the
>> buffer, which overwrites any
>> + // shebang and the binary header while also ensuring the
>> data is aligned on a proper
>> + // object grain boundary,
>> + metaData = (ProgramMetaData *)buffer->getData();
>> +
>> // we now have the encoded data, decode it in place,
>> overwriting the compiled header
>> - if (!StringUtil::decodeBase64(beginEncodedData,
>> encodedLength, data, decodedLength))
>> + if (!StringUtil::decodeBase64(beginEncodedData,
>> encodedLength, buffer->getData(), decodedLength))
>> {
>>
>> reportException(Error_Program_unreadable_invalid_encoding, fileName);
>> }
>> Index: ProgramMetaData.hpp
>>
>> ===================================================================
>>
>> --- ProgramMetaData.hpp (revision 12325)
>>
>> +++ ProgramMetaData.hpp (working copy)
>>
>> @@ -80,8 +80,16 @@
>>
>> uint16_t imageVersion; // version identifier for
>> validity
>> uint16_t wordSize; // size of a word
>> uint16_t bigEndian; // true if this is a
>> big-endian platform
>> - LanguageLevel requiredLevel; // required language level
>> for execution
>> + uint32_t requiredLevel; // required language level
>> for execution (NB: this needs to be an explicitly sized item)
>> uint32_t reserved; // padding to bring
>> imageSize to a 64-bit boundary
>> +
>> + size_t pad; // We need to add an extra
>> pad here to force imageData field to be on an object grain
>> + // boundary so front of the
>> buffer can be chopped off without creating an invalid object.
>> + // The offset of imageData
>> needs to be in integral number of grain increments from the beginning.
>> + // so for 32 bits we are 16
>> + 4*2 + 2*4 + 4 + 4 = 40 bytes for the offset, and
>> + // for 64-bit we are 16 +
>> 4*2 + 2*4 + 8 + 8 bytes for the offset. This will allow things
>> + // go aligned on a grain
>> boundary on all architectures//
>> +
>> size_t imageSize; // size of the image
>> char imageData[4]; // the copied image data
>> };
>>
>> Do these changes invalidate compiled ooRexx programs (with the "-e"
>> switch) that got compiled
>> before these two changes took effect by any chance?
>>
>> ---rony
>>
>>
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
