> 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]> >> 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 > _______________________________________________ > Oorexx-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/oorexx-devel
_______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
