The deep links to the VBISAM versions uploaded by Ron are:
rjnorman74.users.sourceforge.net/vbisam-2.0.tar.Z
rjnorman74.users.sourceforge.net/vbisam-2.1.1.tar.Z
I'd consider them the most stable ones on non-win32 environments (possibly there, too, I just haven't checked recently).
Simon
Am 24.06.20 um 15:08 schrieb Ron
Norman:
I have made similar updates to VBISAM 2.0 and 2.1.1 which also have support for 'suppressed key' that is used by GnuCOBOL as SUPPRESS WHEN ALL '?'.I have reposted a copy of this as follows:
>sftp rjnorman74@xxxxxxxxxxxxxxxxxxx
Password:
Connected to frs.sourceforge.net.
sftp> cd /home/user-web/rjnorman74/htdocs
sftp> pwd
Remote working directory: /home/user-web/rjnorman74/htdocs
sftp> ls -la
drwxr-xr-x 1 rjnorman74 48 2 Jun 19 13:24 .
dr-xr-xr-x 1 rjnorman74 48 2 Oct 12 2012 ..
-rw-r--r-- 1 rjnorman74 48 550876 Jun 24 13:05 vbisam-2.0.tar.Z
-rw-r--r-- 1 rjnorman74 48 591584 Jun 24 13:05 vbisam-2.1.1.tar.Z
On Tue, Jun 23, 2020 at 7:16 PM James K. Lowden <jklowden@xxxxxxxxxxxxxxx> wrote:
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
--
CheersRon Norman
