Bywater BASIC Interpreter / Bugs / #10 Possibly silent but latent bug in bwb_var.c caught with a more modern compiler.

Clement T. Cole - 2020-10-27

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.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Ted A. Campbell - 2020-10-27
  
  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
  
  On Oct 27, 2020, at 2:38 PM, Clement T. Cole clemc@users.sourceforge.net wrote:
  
  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.
  
  [bugs:#10] https://sourceforge.net/p/bwbasic/bugs/10/ Possibly silent but latent bug in bwb_var.c caught with a more modern compiler.
  
  Status: open
  Group: v1.0 (example)
  Created: Tue Oct 27, 2020 07:34 PM UTC by Clement T. Cole
  Last Updated: Tue Oct 27, 2020 07:34 PM UTC
  Owner: Ted A. Campbell
  
  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.cthat 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.
  
  Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/bwbasic/bugs/10/ https://sourceforge.net/p/bwbasic/bugs/10/
  To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/ https://sourceforge.net/auth/subscriptions/
  
  Related
  
  Bugs: #10
  
  alternate
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Jeronimo Pellegrini - 2020-11-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?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Clement T. Cole - 2020-11-10
  
  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:
  
  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?
  
  [bugs:#10] https://sourceforge.net/p/bwbasic/bugs/10/ Possibly silent
  but latent bug in bwb_var.c caught with a more modern compiler.*
  
  Status: open
  Group: v1.0 (example)
  Created: Tue Oct 27, 2020 07:34 PM UTC by Clement T. Cole
  Last Updated: Tue Oct 27, 2020 07:38 PM UTC
  Owner: Ted A. Campbell
  
  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.cthat 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 warning1 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.cbwb_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.
  
  Sent from sourceforge.net because you indicated interest in
  https://sourceforge.net/p/bwbasic/bugs/10/
  
  To unsubscribe from further messages, please visit
  https://sourceforge.net/auth/subscriptions/
  
  Related
  
  Bugs: #10
  
  alternate
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - Clement T. Cole - 2020-11-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:
    
    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:
    
    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?
    
    [bugs:#10] https://sourceforge.net/p/bwbasic/bugs/10/ Possibly silent
    but latent bug in bwb_var.c caught with a more modern compiler.*
    
    Status: open
    Group: v1.0 (example)
    Created: Tue Oct 27, 2020 07:34 PM UTC by Clement T. Cole
    Last Updated: Tue Oct 27, 2020 07:38 PM UTC
    Owner: Ted A. Campbell
    
    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.cthat 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 warning1 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.cbwb_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.
    
    Sent from sourceforge.net because you indicated interest in
    https://sourceforge.net/p/bwbasic/bugs/10/
    
    To unsubscribe from further messages, please visit
    https://sourceforge.net/auth/subscriptions/
    
    Related
    
    Bugs: #10
    
    alternate
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
    - Jeronimo Pellegrini - 2020-11-11
      
      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 in bwb_int.c, and it calls function buff_skip_seperator, which has this comment:
      
      /* skip the next non-space character in 'buffer' if it is a seperator (comma, semicolon, or colon). if successful then 'position' is updated past the character and returns the character skipped otherwise 'position' is unchanged and returns NulChar. */
      
      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:
      
      10 COMMON A(,,,), B(,,,)
      
      does not trigger a syntax error.
      
      Maybe the developers can shed some light on this (I was just passing by...)
      
      If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
      - Jeronimo Pellegrini - 2020-11-11
        
        the extra semicolon there seems to be wrong
        
        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.
        
        If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Hi there,

By Feb 5, 2022:

Using gcc v10.2.1 and bwbasic 3.20, i got this error too.

$ gcc -o bwbasic -lm -ansi -pedantic -Wall -Werror bw*.c
bwb_fnc.c: In function ‘IntrinsicFunction_execute’:
bwb_fnc.c:966:13: error: implicit declaration of function ‘putenv’; did you mean ‘getenv’? [-Werror=implicit-function-declaration]
  966 |         if (putenv (A) == -1)
      |             ^~~~~~
      |             getenv
cc1: all warnings being treated as errors
bwb_var.c: In function ‘bwb_COMMON’:
bwb_var.c:113:9: error: this ‘while’ clause does not guard... [-Werror=misleading-indentation]
  113 |         while (line_skip_seperator (l));
      |         ^~~~~
bwb_var.c:114:9: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘while’
  114 |         {
      |         ^
cc1: all warnings being treated as errors

Related to bwb_var.c, if i remove the comma ";" the erros are fixed, but putenv issue in bwb_fnc.c is still there.

JohnT - 2022-02-06

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.

👍
1

Last edit: JohnT 2022-02-06

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Daniel D. Rodrigues - 2022-02-06
  
  I am using this command, from INSTALL file:
  gcc -o bwbasic -lm -ansi -pedantic -Wall -Werror bw*.c
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Daniel D. Rodrigues - 2022-02-06
  
  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!
  
  🎉
  1
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

AF5NE - 2022-02-19

My apologies for the late response -- I'm not often online.
Please remove the trailing semicolon.

OLD:

while (line_skip_seperator (l));

NEW:

while (line_skip_seperator (l))
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Possibly silent but latent bug in bwb_var.c caught with a more modern compiler.

Group

Searches

Help

#10 Possibly silent but latent bug in bwb_var.c caught with a more modern compiler.

Related

Discussion

Related

Related

Related