Menu ▾ ▴

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

v1.0 (example)
closed
Ted A. Campbell
None
5
2024-11-13
2020-10-27
Clement T. Cole
No

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.

Related

Bugs: #10

Discussion

  • Clement T. Cole

    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.

     

    • Ted A. Campbell

      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

  • Jeronimo Pellegrini

    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?

     

    • Clement T. Cole

      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?

      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

      • Clement T. Cole

        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?

        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

        • Jeronimo Pellegrini

          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...)

           

          • Jeronimo Pellegrini

            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.

             

  • Daniel D. Rodrigues

    Daniel D. Rodrigues - 2022-02-05

    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

    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

    • Daniel D. Rodrigues

      Daniel D. Rodrigues - 2022-02-06

      I am using this command, from INSTALL file:
      gcc -o bwbasic -lm -ansi -pedantic -Wall -Werror bw*.c

       

    • Daniel D. Rodrigues

      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

  • AF5NE

    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))
     

  • Paul Edwards

    Paul Edwards - 2024-11-13
    • status: open --> closed
     

  • Paul Edwards

    Paul Edwards - 2024-11-13

    This patch should now be incorporated in the just-released 3.30

     

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.