BUGFIX: TDB.C and TDBTOOL.C from Jul 9th CVS snapshot.

[John E. Malmberg]

What am I really trying to fix?  I have an ino_t that is larger than the
maximum supported scaler integer type that can be handled on one of my
build platforms.

Unfortunately back when C compilers where just becoming popular,
the implementation of the stat() function was defined on VMS to be
slightly incompatable with UNIX.

The problem is that the ino_t type on OpenVMS is

"unsigned short st_ino[3]"

This basically breaks building any UNIX program that uses the ino_t
datatype on OpenVMS.

This basically requires that all asignment or comparisons of the ino_t
type data be done through memcpy() or memcmp().  Use of these routines
is overkill for the other platforms, and while macros could be used like
ino_t_cpy() and ino_t_cmp(), it may be overkill for other systems.


I have requested that this be fixed in OpenVMS, but I do not know if and
when it would be done, and that would be in a future release, which does
not help me now.  It would also likely only be fixed on the 64 bit
platforms, and not the 32 bit VAX platform.  And there seems to be a lot
of OpenVMS VAX systems running SAMBA, to judge form the E-mails I have
received.

The Compaq C compiler for OpenVMS VAX can not deal with an integer data
type larger than 32 bits.  It must be represented as an array or a
structure.

And apparently nothing in The Open Group's official "Single Unix Standard"
actually states the the ino_t must be a scaler, so it can not be flaged as
a compliance bug.

So as a work around, I defined a structure that maps the smb_ino_t to the
first 32 bytes of the OpenVMS "st_ino".  Based on what SAMBA is doing, and
the documented structure of the OpenVMS inode, this is good enough to get
by on.  The best solution for me would be to use the macros I mentioned
above.


When SAMBA was changed to use SMB_STRUCT_STAT, it removed the reason for
several #ifdef __VMS hacks in the VMS specific port.  It was a big help!


I have SMB_STRUCT_STAT defined to the name of that new structure.
#define SMB_STRUCT_STAT fport__stat_st

I also have

#define stat(a, b) fport__stat(a, (fport__stat_st *) b)

That catches those modules in SAMBA that should use SMB_STRUCT_STAT but
do not.  Unfortunately that trick is broken with the VFS structure, as
there is again a namespace collision.

The problem is that the function stat() and the struct stat have the same
name, so I can not just use #define to get around this.

There may be another way to work around this, but even if a
#define TDB_STRUCT_STAT could be used, it would help me.

I really would prefer to use the method of wrapping the macros around the
references to the references of the data of type ino_t, and then having
config.h cause those macros to default to the UNIX code.  I was not sure
that radical of a patch would be accepted though.  It would also require
more maintenance, as a UNIX programmer would not see the need for the
macros when making a change.

-John
Personal Opinion Only
wb8tyw at qsl.network


On Tue, 10 Jul 2001, Jeremy Allison wrote:

> "John E. Malmberg" wrote:
> 
> > TDB.C
> > 
> > OpenVMS needs the SMB_STRUCT_STAT to be used instead of struct stat on any
> > module that references st_ino.  On OpenVMS st_ino in struct stat is
> > unsigned short[3].
> > 
> > TDB_C.DIFF
> > ************
> > File PROJECT_ROOT:[SAMBA_VMS.SOURCE.TDB]TDB.C;2
> >   233   /*      struct stat st; */
> >   234           SMB_STRUCT_STAT st;
> >   235           if (len <= tdb->map_size) return 0;
> > ******
> > File PROJECT_ROOT:[SAMBA_VMS.SOURCE.TDB]TDB.C;1
> >   233           struct stat st;
> >   234           if (len <= tdb->map_size) return 0;
> > ************
> > ************
> > File PROJECT_ROOT:[SAMBA_VMS.SOURCE.TDB]TDB.C;2
> >  1258   /*      struct stat st; */
> >  1259           SMB_STRUCT_STAT st;
> >  1260           int rev = 0, locked;
> > ******
> > File PROJECT_ROOT:[SAMBA_VMS.SOURCE.TDB]TDB.C;1
> >  1257           struct stat st;
> >  1258           int rev = 0, locked;
> > ************
> 
> I don't understand why this fix is needed.
> 
> st_ino in the tdb code is simply assigned between
> a tdb struct from the stat struct. Why does this fail
> for any data type ?
> 
> We don't want to add Samba dependencies into tdb as it
> is independent of the Samba code (it's hosted on sourceforge).
> 
> Can you explain what you're trying to fix please ?
> 
> Thanks,
> 
> 	Jeremy.
> 
> -- 
> --------------------------------------------------------
> Buying an operating system without source is like buying
> a self-assembly Space Shuttle with no instructions.
> --------------------------------------------------------
>