Dear P.O., On 24.01.2022 13:17, P.O. Jonsson wrote: > 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.
Sure, good luck with Jenkins! ---rony > > >> Am 24.01.2022 um 12:48 schrieb Rony G. Flatscher <[email protected] >> <mailto:[email protected]>>: >> >> 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 <[email protected]>: >>>> >>>> >>>> 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 <[email protected] >>>> <mailto:[email protected]>> 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 [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
