[Info-vax] Compatibility and 64-bit

[Stephen Hoffman]

On 2015-03-15 17:37:38 +0000, JF Mezei said:

> On 15-03-15 03:08, David Froble wrote:
> 
>> About the string descriptors ....
> 
> 
> Question:
> 
> Say i have a C program.
> 
> I define
> 
> mydescriptor struct dsc$descriptor ;  (forgot the actial precise name).

If you are at all unsure of the structure of a 32-bit or 64-bit string 
descriptor, then you will want to review that.

> That descriptor contains (from memory, pardon lack of precision)
> 
> char type;
> char class;
> short lenght;
> void *pointer ;   (or is it unsignec char *pointer ?)

Have a look at descrip.h or dscdef.h, depending on whether you want to 
see the structures and macros provided by the C folks, or if you want 
to review the canonical descriptor header file structures from the 
OpenVMS definitions.

> Why would my program care whether "pointer" was allocated as 4 or 8 bytes ?

Well, there's that recompiling what you've shown using long pointers 
would not produce a valid 64-bit OpenVMS string descriptor.   
Accounting for the structure alignment padding that would generally 
apply here by default (q.v. member alignment, natural alignment, etc), 
you'll get a 16 byte "descriptor" structure with four empty bytes 
starting at byte offset 4.  Routines expecting 32-bit data structures 
will therefore get garbage in the pointer, and routines expecting 
64-bit descriptors — which are formatted differently than 32-bit 
descriptors due to changes in field sizes and particularly for the 
ability of APIs to distinguish the format — will get garbage in most 
fields.  But if you're calling around inside your own code, and not 
passing around structures between 32- and 64-bit environments, what 
you've shown will work correctly (modulo C syntax errors).

> If the program is compiled with a switch that makes all pointers 64
> bits, then all my operations to move pointers around should be 64 bits
> and this is transparent to me.

So long as you're only working within your own code, sure.  Works 
great.  Have at.

> If I dynamically allocate memory to make an array of descriptors, then I
> will likely use  sizeof(struct dsc$descriptor) when calculating how much
> memory to allocate, so whether compiled in 32 or 64 bits, the code will
> still work.

Your code calling around within your code is entirely your code, and 
entirely up to you.   If you want to call OpenVMS calls, then you need 
to play using OpenVMS-format descriptors.

> And when I manipulate a pointer, I am expected to always use pointer
> variables, right ?  I am NOT supposed to move a pointer to an integer,
> have fun with it as integer and then move it back to a pointer variable,
> right?

See <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf> section 
6.3.2.3 starting on page 55,.  Casting an integer value of zero is OK, 
other the results of other operations are implementation-defined.

> Ever since VMS started to support both 32 and 64 bits, I have been weary
> of assuming the size of any variable and always use sizeof when I need
> to knwo it size.

Though the sizeof also changes across one of these 32-to-64-bit 
migrations, but there are cases where compatibility is necessary across 
versions for data structures stored in files or network packets.

> Yeah, when dealing with integers, you want to make sure you have the
> right incantation to have the right bit size. For instance, for VMS
> time, you can safely use a quadword, but if you know the language well
> enough, you can also allocate a 64 bit integer and do the math directly
> to it , instead of calling the routines that add/subtract time.

For the modern OpenVMS time storage, proper "binary" storage is twenty 
bytes IIRC, and not a quadword.

> But for pointers, I am not sure I understand where the problem is.

There are, of course, many other sorts of descriptors on OpenVMS, too.

Start with the materials and examples that I referenced in the earlier reply.



-- 
Pure Personal Opinion | HoffmanLabs LLC