Re: [mtools] Mtools 3.9.10 for VMS

[Steven M. Schweda]

   I believe that I have a good patch kit to add VMS support to mtools
3.9.10 with the 20060531 patch kit applied:

     
ftp://antinode.org/mtools/mtools-3_9_10_20060531/mtools-3_9_10_20060531_vms.diff-gz
     
http://antinode.org/ftp/mtools/mtools-3_9_10_20060531/mtools-3_9_10_20060531_vms.diff-gz

Command used:
      gdiff -urN mtools-3.9.10_20060531 mtools-3.9.10_20060531_vms

That kit includes the new "vms" subdirectory.  If something else would
be better, or if anyone has any questions or complaints, please let me
know.

   The resulting kit could be built on Tru64 UNIX using gcc or
DEC/Compaq/HP C, but the build, while better, is still not clean.  The
remaining compiler complaints follow.

========================================================================

urtx# cc -V
Compaq C V6.5-303 (dtk) on Compaq Tru64 UNIX V5.1B (Rev. 2650)
Compiler Driver V6.5-302 (dtk) cc Driver

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

cc  -DHAVE_CONFIG_H -DSYSCONFDIR=\"/usr/local/etc\" -DCPU_alphaev6 -DVENDOR_dec
-DOS_osf5_1b -DOS_osf5 -DOS_osf  -g -fno-strict-aliasing -I.  -I.   -c llong.c
cc: Warning: llong.c, line 18: In the initializer for max_off_t_seek, integer ov
erflow occurs in evaluating the expression
"((mt_off_t)1<<(((sizeof(off_t)*8-1))
<(sizeof(mt_off_t)*8-1)?((sizeof(off_t)*8-1)):(sizeof(mt_off_t)*8-1)))-1". (into
verfl)
const mt_off_t max_off_t_seek = MAX_OFF_T_B(SEEK_BITS); /* SCSI */
--------------------------------^

More "#pragma" directives could help here.  Perhaps changing "#ifdef
__VMS" to "#ifdef __DECC" would quiet two compilers with one mess.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

cc  -DHAVE_CONFIG_H -DSYSCONFDIR=\"/usr/local/etc\" -DCPU_alphaev6 -DVENDOR_dec
-DOS_osf5_1b -DOS_osf5 -DOS_osf  -g -fno-strict-aliasing -I.  -I.   -c mformat.c
cc: Info: mformat.c, line 1150: In this statement, an array is being accessed ou
tside the bounds specified for the array type. (subscrbounds)
                set_word(boot->jump + 510, 0xaa55);
--------------------------------------^

   A union here (with a bigger array) could probably cure this one, but
some work/thought would be needed.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

cc   -DHAVE_CONFIG_H -DSYSCONFDIR=\"/usr/local/etc\" -DCPU_alphaev6 -DVENDOR_dec
 -DOS_osf5_1b -DOS_osf5 -DOS_osf  -g -fno-strict-aliasing -I.  -I.   -c floppyd.
c floppyd.c
floppyd.c:
cc: Warning: floppyd.c, line 724: In this statement, the referenced type of the
pointer value "&len" is "unsigned int", which is not compatible with "int" becau
se they differ by signed/unsigned attribute. (ptrmismatch1)
                while ((new_sock = accept(sock, (struct sockaddr *)&addr, &len))
 < 0){}
--------------------------------------------------------------------------^

cc: Warning: floppyd.c, line 865: In this statement, the referenced type of the
pointer value "&len" is "unsigned int", which is not compatible with "int" becau
se they differ by signed/unsigned attribute. (ptrmismatch1)
                if(getsockname(0, (struct sockaddr*) &addr, &len) >= 0 &&
------------------------------------------------------------^

   I don't build "floppyd" on VMS, but I'll bet that the complaints
would be similar.  I assume that the "unsigned int len" declarations at
lines 711 and 862 should really be "int len" (or else more type casts).

========================================================================

urtx# gcc -v
Reading specs from /usr/local/lib/gcc/alpha-dec-osf5.1/3.4.5/specs
Configured with: /usr/local/gnu/gcc-3.4.5/configure
Thread model: posix
gcc version 3.4.5

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

   Lots of "warning: subscript has type `char'".

   Some "warning: int format, different type arg (arg x)".

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

gcc  -DHAVE_CONFIG_H -DSYSCONFDIR=\"/usr/local/etc\" -DCPU_alphaev6 -DVENDOR_dec
 -DOS_osf5_1b -DOS_osf5 -DOS_osf  -g -O2 -Wall -fno-strict-aliasing -I.  -I.   -
c llong.c
llong.c:12:2: warning: #warning "The following warnings about integer overflow i
n expression can be safely ignored"
llong.c:21: warning: integer overflow in expression

   As expected.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

gcc  -DHAVE_CONFIG_H -DSYSCONFDIR=\"/usr/local/etc\" -DCPU_alphaev6 -DVENDOR_dec
 -DOS_osf5_1b -DOS_osf5 -DOS_osf  -g -O2 -Wall -fno-strict-aliasing -I.  -I.   -
c plain_io.c
In file included from plain_io.c:40:
lockdev.h: In function `lock_dev':
lockdev.h:32: warning: implicit declaration of function `flock'

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

gcc  -DHAVE_CONFIG_H -DSYSCONFDIR=\"/usr/local/etc\" -DCPU_alphaev6 -DVENDOR_dec
 -DOS_osf5_1b -DOS_osf5 -DOS_osf  -g -O2 -Wall -fno-strict-aliasing -I.  -I.   -
c unixdir.c
unixdir.c: In function `unix_dir_loop':
unixdir.c:149: warning: implicit declaration of function `fchdir'

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

   Around here, "man flock" suggests <sys/fcntl.h>, and "man fchdir
suggests <unistd.h>.  I haven't looked at what's happening here.  I did
notice that the "config.h" files differed:

urtx# diff config.h_cc config.h_gcc
155c155
< #define HAVE_STDINT_H 1
---
> /* #undef HAVE_STDINT_H */

It's possible that an OS upgrade since the GCC installation has messed
up something in the header files here.

------------------------------------------------------------------------

   Steven M. Schweda               address@hidden
   382 South Warwick Street        (+1) 651-699-9818
   Saint Paul  MN  55105-2547
_______________________________________________
mtools mailing list
address@hidden
http://www.tux.org/mailman/listinfo/mtools