Bug 1891 - OpenVMS ino_t is 48 bits on VAX and older VMS releases.
Summary: OpenVMS ino_t is 48 bits on VAX and older VMS releases.
Status: RESOLVED WONTFIX
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: Config Files (show other bugs)
Version: 3.0.7
Hardware: Other OpenVMS
: P3 enhancement
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-10-08 11:48 UTC by John Malmberg
Modified: 2010-04-26 03:45 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John Malmberg 2004-10-08 11:48:36 UTC
Platform set to "OTHER" as primarily affects VAX.

The ino_t type on OpenVMS VAX is 48 bits and can not be represented as an
integer type, as the largest integer type that can be handled by the compiler is
32 bits.

The supplied OpenVMS header files provide the ino_t type as unsigned short [3].

It is also possible to provide an alternate representation of the ino_t type as
a structure containing three unsigned short members.

This is essentially also the case for OpenVMS on Alpha prior to Version 8.2.

In order to accomodate OpenVMS VAX, etcetera, memcpy() and memcmp() need to used
on ino_t operations, or loss of data will occur.

As the overhead for memcpy() and memcmp() (assuming the compiler does not
optimize the calls) is not needed for other cases, including OpenVMS 8.2 on
Alpha and Itaninum, the proposed change would be to use a set of macros to do
the assignment and comparison.

These macros would default to making a direct assignment or compare, unless
there is an existing macro defined in the config.h file.
Comment 1 Stefan Metzmacher 2010-04-26 03:45:20 UTC
If it's still broken in 3.5, please reopen.
3.0 isn't supported anymore.