Yes they do.
On Thu, Jan 20, 2022 at 12:52 PM Rony G. Flatscher <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
