David James wrote:

Should the different variants in a variant record overlay in the same memory?

Previous Pascals I have used have guaranteed this, and I've got low-level code that relies on this.

[...]

(I know the variants are not the same length, and they are intended not to be.)

As you assumed in your latter mail, this is intentional so the discriminants are not overwritten, and they can be properly initialized in the first place. Consider:

record case Boolean of False: (s1 : String (42)); True: (s2 : String (99)); end;

If the strings would overlay, in particular their disriminants would occupy the same place in memory. How should it be initialized? Either way, it would be wrong for at least one of the variants...

So, after a discussion in comp.lang.pascal.ansi-iso where this topic came up concerning file variables (which also require some automatic initialization and finalization), we decided to do this in GPC for all types with automatic initialization and finalization (currently files and schemata, in the future this might also be Delphi compatible classes and user-defined initialized and finalized types), since the standard does not guarantee variants to overlay, anyway...

There are two ways in GPC to get guaranteed overlaying (both non-standard, of course, since the standard does not assume anything about internal representations; both BP compatible), `absolute' declarations and variable type casts. E.g., in order to overlay a byte array to a variable v:

var b: array [1 .. SizeOf (v)] of Byte absolute v;

or

type t = array [1 .. SizeOf (v)] of Byte;

then `t (v)' can be used as a byte array overlayed to v.

Russ Whitaker wrote:

You have more than an overlay problem. In standard pascal you expect ic[ 1 ] to align with the first character position of s and thus one character to the left is the length of s. Thus ic[0] is the length of s.

This holds for UCSD/BP strings (which GPC does not yet implement, but that's planned). The only strings Standard Pascal knows are arrays of char without any length value.

Two different kinds of strings with the same name - string - does make a bit of confusion. Perhaps the oldstyle strings could be renamed "short string" ?? ( didn't think changing the spelling to "stwing" would fly )

When we implement the short strings, we'll have to do such a distinction. Our current planning goes like this:

string (n): string schema (EP compatible)

string [n]: short string (UCSD/BP compatible, where n must be <= 255)

string: dependent on flags, by default undiscriminated schema, but in BP mode (or with a special switch) short string of capacity 255 (UCSD/BP compatible).

Frank