Dera Rony,
I have no comments on the change itself, but could you please wait a day or two
with this change? We are experiencing problems with the Jenkins build system at
the moment. I will let you know when it has been fixed.
Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se
> Am 24.01.2022 um 12:48 schrieb Rony G. Flatscher <rony.flatsc...@wu.ac.at>:
>
> 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>
>>> <mailto: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
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
