Possible bug in bwb_var.c
When I was compiling with a modern compiler (icc) on my Mac, [not clang also gets the same warning] to try to run a very old BASIC program and I noticed something in bwb_var.c
that is inconsistent as a minimum and possibly a very latent bug.
I found this quite by accident and I admit, I have not taken this very far, other than I noticed that the source forge has a 2017 as the last release .20 and maybe some one else has noticed this with a newer compiler.
bwb_var.c:113:40: warning: while loop has empty body [-Wempty-body] while (line_skip_seperator (l)); ^ bwb_var.c:113:40: note: put the semicolon on a separate line to silence this warning 1 warning generated.
So I looked at code: [lines 97-123]
if (line_skip_LparenChar (l)) { line_skip_spaces (l); /* keep this */ if (bwb_isdigit (l->buffer[l->position])) { /* COMMON A(3) : DIM A( 5, 10, 20 ) */ if (line_read_integer_expression (l, &dimensions) == FALSE) { WARN_SYNTAX_ERROR; return (l); } } else { /* COMMON A(,,) : DIM A( 5, 10, 20 ) */ dimensions++; while (line_skip_seperator (l)); { dimensions++; } } if (line_skip_RparenChar (l) == FALSE) { WARN_SYNTAX_ERROR; return (l); } }
As a 40+ year C programmer, I'm not so sure the while (foo) ;
on line 113 is what you really intended. The current code is the same as causes dimensions
to be incremented once before the while loop and then again (always) once more time after the while loop. If this is what you really want, then the curly braces around the second dimensions
increment are redunant. However, if you do meant to do that then I agree with the warning and suggest putting the null statement in a line by itself (with a comment). However, if your real intent is increment dimensions each time you call line_skip_seperator()
with a non_zero return, that is not happenning.
Also, FWIW: the file bwb_cmd.c
gets another 27 warnings like this which I have not explored:
gcc -c -I. -DHAVE_STRING=1 -DHAVE_STDLIB=1 -DHAVE_UNISTD=1 -DHAVE_RAISE=1 -g -ansi -DHAVE_UNIX bwb_cmd.c bwb_cmd.c:6263:31: warning: format string is not a string literal (potentially insecure) [-Wformat-security] fprintf (My->SYSOUT->cfp, IntrinsicCommandTable[n].name);
I suspect these are two deeply nested into the design to want to reconsider replacements, they are all in the use the format string, which can be an attack vector, hence the comp[iler warnings.
I ran into this accidently. I know its old code, but I think the compiler is on to something. If the code is as intended, then it probably needs to be reformated to be a tad more explicit as per the warning, but I'm thinking there might be something that was missed for many years.
I would encourage you to correct this. I’m the original author but I have not worked with the code for a decade or more, /ted
—
Ted A. Campbell
tc@tedcampbell.com
Related
Bugs: #10
I guess the compiler got it wrong. The code is counting commas in "
DIM(,,,)
".And if the formatting changed, it would be inconsistend with the rest of the code (which uses the opening brace in the next line)
What compiler issued that warning?
Nice catch -- always possible -- C compiler is clang Apple Version 11 (
a.k.a. LLVM see below). You might want to add a note, that it might not
compiler with a clang compiler front-end.
Using:
sh-3.2$ make clean
rm -f .o bwbasic core
sh-3.2$ CC=gcc-10
sh-3.2$ export CC
sh-3.2$ ./configure
checking how to run the C preprocessor
checking for install
checking for size_t in sys/types.h
checking for string.h
checking for stdlib.h
checking for unistd.h
checking for raise
creating config.status
creating Makefile
sh-3.2$ make
gcc-10 -c -I. -DHAVE_STRING=1 -DHAVE_STDLIB=1 -DHAVE_UNISTD=1
-DHAVE_RAISE=1 -g -ansi -DHAVE_UNIX bwbasic.c
gcc-10 -c -I. -DHAVE_STRING=1 -DHAVE_STDLIB=1 -DHAVE_UNISTD=1
-DHAVE_RAISE=1 -g -ansi -DHAVE_UNIX bwb_cmd.c
gcc-10 -c -I. -DHAVE_STRING=1 -DHAVE_STDLIB=1 -DHAVE_UNISTD=1
-DHAVE_RAISE=1 -g -ansi -DHAVE_UNIX bwb_cnd.c
gcc-10 -c -I. -DHAVE_STRING=1 -DHAVE_STDLIB=1 -DHAVE_UNISTD=1
-DHAVE_RAISE=1 -g -ansi -DHAVE_UNIX bwb_dio.c
gcc-10 -c -I. -DHAVE_STRING=1 -DHAVE_STDLIB=1 -DHAVE_UNISTD=1
-DHAVE_RAISE=1 -g -ansi -DHAVE_UNIX bwb_exp.c
gcc-10 -c -I. -DHAVE_STRING=1 -DHAVE_STDLIB=1 -DHAVE_UNISTD=1
-DHAVE_RAISE=1 -g -ansi -DHAVE_UNIX bwb_fnc.c
gcc-10 -c -I. -DHAVE_STRING=1 -DHAVE_STDLIB=1 -DHAVE_UNISTD=1
-DHAVE_RAISE=1 -g -ansi -DHAVE_UNIX bwb_inp.c
gcc-10 -c -I. -DHAVE_STRING=1 -DHAVE_STDLIB=1 -DHAVE_UNISTD=1
-DHAVE_RAISE=1 -g -ansi -DHAVE_UNIX bwb_int.c
gcc-10 -c -I. -DHAVE_STRING=1 -DHAVE_STDLIB=1 -DHAVE_UNISTD=1
-DHAVE_RAISE=1 -g -ansi -DHAVE_UNIX bwb_prn.c
gcc-10 -c -I. -DHAVE_STRING=1 -DHAVE_STDLIB=1 -DHAVE_UNISTD=1
-DHAVE_RAISE=1 -g -ansi -DHAVE_UNIX bwb_stc.c
gcc-10 -c -I. -DHAVE_STRING=1 -DHAVE_STDLIB=1 -DHAVE_UNISTD=1
-DHAVE_RAISE=1 -g -ansi -DHAVE_UNIX bwb_str.c
gcc-10 -c -I. -DHAVE_STRING=1 -DHAVE_STDLIB=1 -DHAVE_UNISTD=1
-DHAVE_RAISE=1 -g -ansi -DHAVE_UNIX bwb_tbl.c
gcc-10 -c -I. -DHAVE_STRING=1 -DHAVE_STDLIB=1 -DHAVE_UNISTD=1
-DHAVE_RAISE=1 -g -ansi -DHAVE_UNIX bwb_var.c
gcc-10 -c -I. -DHAVE_STRING=1 -DHAVE_STDLIB=1 -DHAVE_UNISTD=1
-DHAVE_RAISE=1 -g -ansi -DHAVE_UNIX bwd_cmd.c
gcc-10 -c -I. -DHAVE_STRING=1 -DHAVE_STDLIB=1 -DHAVE_UNISTD=1
-DHAVE_RAISE=1 -g -ansi -DHAVE_UNIX bwd_fun.c
gcc-10 -c -I. -DHAVE_STRING=1 -DHAVE_STDLIB=1 -DHAVE_UNISTD=1
-DHAVE_RAISE=1 -g -ansi -DHAVE_UNIX bwx_tty.c
gcc-10 bwbasic.o bwb_cmd.o bwb_cnd.o bwb_dio.o bwb_exp.o bwb_fnc.o
bwb_inp.o bwb_int.o bwb_prn.o bwb_stc.o bwb_str.o bwb_tbl.o bwb_var.o
bwd_cmd.o bwd_fun.o bwx_tty.o -lm -o bwbasic
sh-3.2$ make clean
rm -f .o bwbasic core
sh-3.2$ CC=icc
sh-3.2$ export CC
sh-3.2$ ./configure
checking how to run the C preprocessor
checking for install
checking for size_t in sys/types.h
checking for string.h
checking for stdlib.h
checking for unistd.h
checking for raise
creating config.status
creating Makefile
sh-3.2$ make
icc -c -I. -DHAVE_STRING=1 -DHAVE_STDLIB=1 -DHAVE_UNISTD=1 -DHAVE_RAISE=1
-g -ansi -DHAVE_UNIX bwbasic.c
icc -c -I. -DHAVE_STRING=1 -DHAVE_STDLIB=1 -DHAVE_UNISTD=1 -DHAVE_RAISE=1
-g -ansi -DHAVE_UNIX bwb_cmd.c
icc -c -I. -DHAVE_STRING=1 -DHAVE_STDLIB=1 -DHAVE_UNISTD=1 -DHAVE_RAISE=1
-g -ansi -DHAVE_UNIX bwb_cnd.c
icc -c -I. -DHAVE_STRING=1 -DHAVE_STDLIB=1 -DHAVE_UNISTD=1 -DHAVE_RAISE=1
-g -ansi -DHAVE_UNIX bwb_dio.c
icc -c -I. -DHAVE_STRING=1 -DHAVE_STDLIB=1 -DHAVE_UNISTD=1 -DHAVE_RAISE=1
-g -ansi -DHAVE_UNIX bwb_exp.c
icc -c -I. -DHAVE_STRING=1 -DHAVE_STDLIB=1 -DHAVE_UNISTD=1 -DHAVE_RAISE=1
-g -ansi -DHAVE_UNIX bwb_fnc.c
icc -c -I. -DHAVE_STRING=1 -DHAVE_STDLIB=1 -DHAVE_UNISTD=1 -DHAVE_RAISE=1
-g -ansi -DHAVE_UNIX bwb_inp.c
icc -c -I. -DHAVE_STRING=1 -DHAVE_STDLIB=1 -DHAVE_UNISTD=1 -DHAVE_RAISE=1
-g -ansi -DHAVE_UNIX bwb_int.c
icc -c -I. -DHAVE_STRING=1 -DHAVE_STDLIB=1 -DHAVE_UNISTD=1 -DHAVE_RAISE=1
-g -ansi -DHAVE_UNIX bwb_prn.c
icc -c -I. -DHAVE_STRING=1 -DHAVE_STDLIB=1 -DHAVE_UNISTD=1 -DHAVE_RAISE=1
-g -ansi -DHAVE_UNIX bwb_stc.c
icc -c -I. -DHAVE_STRING=1 -DHAVE_STDLIB=1 -DHAVE_UNISTD=1 -DHAVE_RAISE=1
-g -ansi -DHAVE_UNIX bwb_str.c
icc -c -I. -DHAVE_STRING=1 -DHAVE_STDLIB=1 -DHAVE_UNISTD=1 -DHAVE_RAISE=1
-g -ansi -DHAVE_UNIX bwb_tbl.c
icc -c -I. -DHAVE_STRING=1 -DHAVE_STDLIB=1 -DHAVE_UNISTD=1 -DHAVE_RAISE=1
-g -ansi -DHAVE_UNIX bwb_var.c
icc -c -I. -DHAVE_STRING=1 -DHAVE_STDLIB=1 -DHAVE_UNISTD=1 -DHAVE_RAISE=1
-g -ansi -DHAVE_UNIX bwd_cmd.c
icc -c -I. -DHAVE_STRING=1 -DHAVE_STDLIB=1 -DHAVE_UNISTD=1 -DHAVE_RAISE=1
-g -ansi -DHAVE_UNIX bwd_fun.c
icc -c -I. -DHAVE_STRING=1 -DHAVE_STDLIB=1 -DHAVE_UNISTD=1 -DHAVE_RAISE=1
-g -ansi -DHAVE_UNIX bwx_tty.c
icc bwbasic.o bwb_cmd.o bwb_cnd.o bwb_dio.o bwb_exp.o bwb_fnc.o bwb_inp.o
bwb_int.o bwb_prn.o bwb_stc.o bwb_str.o bwb_tbl.o bwb_var.o bwd_cmd.o
bwd_fun.o bwx_tty.o -lm -o bwbasic
I did try it with both icc and gcc-10 also and indeed the issue went away.
This is what is on my Mac:
% gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
--with-gxx-include-dir=/usr/include/c++/4.2.1
Apple clang version 11.0.0 (clang-1100.0.33.17)
Target: x86_64-apple-darwin18.7.0
Thread model: posix
InstalledDir:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
% clang --version
Apple clang version 11.0.0 (clang-1100.0.33.17)
Target: x86_64-apple-darwin18.7.0
Thread model: posix
InstalledDir:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
% ls -l /usr/bin/{gcc,clang}
-rwxr-xr-x 1 root wheel 18288 Jul 29 2019 /usr/bin/clang
-rwxr-xr-x 1 root wheel 18288 Jul 29 2019 /usr/bin/gcc
% uname -a
Darwin ctcole-mac09.localdomain 18.7.0 Darwin Kernel Version 18.7.0: Mon
Aug 31 20:53:32 PDT 2020; root:xnu-4903.278.44~1/RELEASE_X86_64 x86_64 i386
MacBookPro13,3 Darwin
% icc --version
icc (ICC) 19.0.4.233 20190416
Copyright (C) 1985-2019 Intel Corporation. All rights reserved.
% gcc-10 --version
gcc-10 (Homebrew GCC 10.2.0) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
% ls -l /usr/local/bin/gcc-10 /usr/local/Cellar/gcc/10.2.0/bin/gcc-10
-r-xr-xr-x 1 ctcole staff 1538300 Jul 23 02:50
/usr/local/Cellar/gcc/10.2.0/bin/gcc-10
lrwxr-xr-x 1 ctcole admin 31 Aug 4 13:29 /usr/local/bin/gcc-10 ->
../Cellar/gcc/10.2.0/bin/gcc-10
% which gcc;which clang;which gcc-10;which icc
/usr/bin/gcc
/usr/bin/clang
/usr/local/bin/gcc-10
/usr/local/bin/icc
Please note that on a Mac, gcc is mapped to clang (LLVM) by Apple [which I
defaulted for you folks].
So I guess the note is, does not currently build with clang.
I see if I can let someone on the LLVM team know about it here, as the
INTEL*64 backend folks are in my larger team at Intel and they may know
whom to talk too in the C front-end and file a bug report with them.
Thanks for the help,
Clem
On Tue, Nov 10, 2020 at 1:49 PM Jeronimo Pellegrini pellegrini@users.sourceforge.net wrote:
Related
Bugs: #10
BTW: I do stand by my original note and the warning seems reasonable. I'm
curious that icc did not catch it. I wish I had a copy of Gimpel's
pclint() and see what they say. As I said in my original note:
while (line_skip_seperator (l));
{
dimensions++;
}
compiles to/ becomes equiv too:
while (line_skip_seperator (l)) / null statement /;
dimensions++;
not:
while (line_skip_seperator (l)) {
dimensions++;
}
If the code was intended to work as I mentioned, then you might
consider getting rid of the redundant curly braces. I suspect that
maybe what your are intending and clang did give you a warning that
makes sense,
On Tue, Nov 10, 2020 at 2:55 PM Clem Cole clemc@ccc.com wrote:
Related
Bugs: #10
I'm sorry, for some reason I misread something in your original report. I thought the code did not had the comma, and the compiler was suggesting to add it. It is the opposite.
I guess the comma should not be there.
line_skip_seperator
is defined inbwb_int.c
, and it calls functionbuff_skip_seperator
, which has this comment:So the
while
really is counting commas, and the extra semicolon there seems to be wrong.Now... I have compiled with and without the comma, and in both cases this:
does not trigger a syntax error.
Maybe the developers can shed some light on this (I was just passing by...)
Unless the number of dimensions is actually ignored by the
COMMON
statement. Then the actual code would just skip the commas and always return 2 as the number of dimensions, which would not be used later. I don't know if this is the case.Hi there,
By Feb 5, 2022:
Using gcc v10.2.1 and bwbasic 3.20, i got this error too.
Related to bwb_var.c, if i remove the comma ";" the erros are fixed, but putenv issue in bwb_fnc.c is still there.
Daniel, are you building with a makefile or with the commandline? Here's the compilation from my build with makefile, BWBasic 3.20 and I think gcc 10.2.1. gcc -c -I. -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_STRING=1 -DHAVE_STDLIB=1 -DHAVE_UNISTD=1 -DHAVE_RAISE=1 -g -ansi -DHAVE_UNIX bwb_fnc.c
I don't think I've got the makefile treating warnings as errors. It should build and run without that. No errors or warnings in the build. Done on Debian 10.
Last edit: JohnT 2022-02-06
I am using this command, from INSTALL file:
gcc -o bwbasic -lm -ansi -pedantic -Wall -Werror bw*.c
Sorry, I got it now. I read Clement T. Cole's comment and found the solution:
First:
$ gcc -c -I. -DHAVE_STRING=1 -DHAVE_STDLIB=1 -DHAVE_UNISTD=1 -DHAVE_RAISE=1 -g -ansi -DHAVE_UNIX bw*.c
Second:
$ gcc bw*.o -lm -o bwbasic
Run:
./bwbasic
Thank you @JohnT, without you i would never see the solution!
My apologies for the late response -- I'm not often online.
Please remove the trailing semicolon.
OLD:
NEW: