Thank you ver much for this detailed report.
I'll recheck those issue when working on a next "official" VBISAM which
is planned for end of this year and include all the good work put in by
different people before.
I *guess* the patched version published by Ron in the GnuCOBOL
discussion boards have those issues fixed already, but until a new
"official" version is out your report may help someone that wants to
build VBISAM with the base of the the official 2.0 tarball.
Simon
Am 24.06.2020 um 01:16 schrieb James K. Lowden:
> This afternoon I built vbisam from the tarball maintained on
> SourceForge. The build platform is macOS, but for reasons unclear it
> compiled with gcc. Perhaps something to do with libtool.
>
> The build produced a few warnings that I fixed, and a few that sure
> look to me like logic errors that someone familar with the code
> would like to scrutinize.
>
> 2 Changes:
>
> 1. must be a logical error
> 2. simple oversight on a 32-bit machine
>
> diff -u
> libvbisam/vblowlevel.c /Users/jklowden/projects/3/vbisam-2.0/libvbisam/vblowlevel.c
> --- libvbisam/vblowlevel.c 2008-08-28 10:03:52.000000000 -0400
> +++ /Users/jklowden/projects/3/vbisam-2.0/libvbisam/vblowlevel.c
> 2020-06-23 18:30:39.000000000 -0400 @@ -39,7 +39,7 @@
> iinitialized = 1;
> }
> if (stat (pcfilename, &sstat)) {
> - if (!iflags & O_CREAT) {
> + if (!(iflags & O_CREAT)) {
> return -1;
> }
> } else {
> diff -u
> libvbisam/vbmemio.c /Users/jklowden/projects/3/vbisam-2.0/libvbisam/vbmemio.c
> --- libvbisam/vbmemio.c 2008-08-28 13:03:23.000000000 -0400
> +++ /Users/jklowden/projects/3/vbisam-2.0/libvbisam/vbmemio.c
> 2020-06-23 18:30:39.000000000 -0400 @@ -48,7 +48,7 @@
>
> mptr = calloc (1, size);
> if (unlikely(!mptr)) {
> - fprintf (stderr, "Cannot allocate %d bytes of memory -
> Aborting\n", size);
> + fprintf (stderr, "Cannot allocate %zu bytes of memory -
> Aborting\n", size); fflush (stderr);
> exit (1);
> }
>
>
> Other warnings (3):
>
> ../../libvbisam/isdecimal.c:377:10: warning: implicit conversion from
> 'long' to 'int' changes value from 2147483648 to -2147483648
> [-Wconstant-conversion]
> *ip = VAL_DECPOSNULL (int);
>
>
> VAL_DECPOSNULL is:
>
> #define VAL_DECPOSNULL(type) (1L << ((sizeof (type) * 8) - 1))
>
> Because it starts with 1L, it returns a long with bit 32 set. When
> assigned to an int (as the warning states), the positive value becomes
> negative because it's the high bit of the assigned integer.
>
> On a 32-bit machine, long and int were usually the same size, and no
> warning would have been warranted.
>
> I think safest would be:
>
> #define VAL_DECPOSNULL(type) \
> ( ((type)1) << ((sizeof (type) * 8) - 1) )
>
>
>
> --
> ../../libvbisam/vbnodememio.c:497:45: warning: use of logical '&&' with
> constant operand [-Wconstant-logical-operand]
> if (pskey->iishigh && pskeydesc->k_flags && LCOMPRESS) {
>
> LCOMPRESS is defined as
>
> #define LCOMPRESS 0x04 /* Leading compression */
>
> so the logical && is meaningless. I think the intention is
>
> if (pskey->iishigh && (pskeydesc->k_flags & LCOMPRESS)) {
>
> but the result is different, perhaps surprising logic. Instead of any
> value of k_flags making the expression true, it must have the LCOMPRESS
> bit set.
>
>
> --
> ../../libvbisam/vbnodememio.c:501:28: warning: use of logical '&&' with
> constant operand [-Wconstant-logical-operand]
> if (pskeydesc->k_flags && TCOMPRESS) {
>
> Similar to previous: should be bitwise &, but result is new logic.
>
> --jkl
>
