Re: [M100] Building VirtualT
On 3/26/20 9:44 PM, Ken Pettit wrote: Hey Brian, No, I didn't get any of these warnings, but then I didn't have the -Wall flag set. When I set that ... oh my! I will have to go through and do some cleanup ... I don't like warnings! I'm pulling down my github copy because now the sourceforge copy is more up to date. I've cleared all compiler warnings again, starting from your latest on sourceforge, and submitted a merge request. https://sourceforge.net/u/bkw777/virtualt/ https://sourceforge.net/p/virtualt/code/merge-requests/1/ Next up "make install", .desktop launcher, and .deb package. -- bkw
Re: [M100] Building VirtualT
On Thu, Mar 26, 2020 at 7:10 PM Ken Pettit wrote: > > Heck, programmer's have it easy these days ... they get 1's *and* 0's. > When I was a kid, we only had 0's! > > Ken > > Not judging your code or your advanced age ;-) -- John.
Re: [M100] Building VirtualT
Just to be clear, Fedora's distro supplied version of FLTK is 1.3.5 which is the current stable release on fltk.org On Thu, 2020-03-26 at 21:40 -0400, Brian K. White wrote: > On 3/25/20 10:27 AM, Ken Pettit wrote: > > Hey Guys, > > Okay, I have fixed this bug (in src/file.cpp). The de-tokenizer > > was not testing for quoted strings. I pushed the changes to the > > git repo here if anyone wants to pull it and compile prior to an > > official VT 1.8 release: > > git clone https://git.code.sf.net/p/virtualt/code virtualt > > Ken > > Don't you get a lot of these generated by your compiler?This is just > a couple out of many from a fresh git pull.I didn't find these myself > before, I just addressed each compiler warning until there weren't > any more.I'll go through them again and see if sourceforge provides a > way to submit patches back up like gitlab or github. > src/m100emu.c: In function ‘check_installation’:src/m100emu.c:723:39: > warning: ‘%s’ directive writing up to 255 bytes into a region of size > 240 [-Wformat-overflow=] 723 | sprintf(localpath, "No ROM file > for %s", errors); | ^~ > ~~In file included from /usr/include/stdio.h:867, > from src/m100emu.c:32:/usr/include/x86_64-linux- > gnu/bits/stdio2.h:36:10: note: ‘__builtin___sprintf_chk’ output > between 17 and 272 bytes into a destination of size 25636 | > return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1, | > ^~37 | > __bos (__s), __fmt, __va_arg_pack ()); | > ~ > > I also get this, which is probably from me using the latest fltk.But > the changes I made for that apparently didn't break building with the > older versions since Keven Becker said he just used the distro > supplied package. > Linking virtualt/usr/bin/ld: obj/remote.o: in function > `key_delay()':remote.cpp:(.text+0x8f7): undefined reference to > `fl_wait(double)'/usr/bin/ld: remote.cpp:(.text+0x927): undefined > reference to `fl_wait(double)'/usr/bin/ld: obj/remote.o: in function > `cmd_step(ServerSocket&, std::__cxx11::basic_string std::char_traits, std::allocator > >&)':remote.cpp:(.text+0x3279): undefined reference to > `fl_wait(double)'/usr/bin/ld: obj/remote.o: in function > `cmd_step_over(ServerSocket&, std::__cxx11::basic_string std::char_traits, std::allocator > >&)':remote.cpp:(.text+0x3577): undefined reference to > `fl_wait(double)'/usr/bin/ld: remote.cpp:(.text+0x3639): undefined > reference to `fl_wait(double)'/usr/bin/ld: > obj/remote.o:remote.cpp:(.text+0xb066): more undefined references to > `fl_wait(double)' followcollect2: error: ld returned 1 exit > statusmake: *** [GNUmakefile:124: virtualt] Error 1 > > Assuming sourceforge provides a way to submit merge requests I'll do > that shortly. >
Re: [M100] Building VirtualT
On 3/26/20 7:00 PM, John R. Hogerhuis wrote: Don't ask, don't tell :-) sprintf at least is inherently dangerous and should never be used. Should always use snprintf so you're committing to a certain buffer size. Yep. But then again, almost all of this code was written over 10 year ago. Did they even have snprintf then! ;) Heck, programmer's have it easy these days ... they get 1's *and* 0's. When I was a kid, we only had 0's! Ken
Re: [M100] Building VirtualT
On 3/26/20 9:44 PM, Ken Pettit wrote: Hey Brian, No, I didn't get any of these warnings, but then I didn't have the -Wall flag set. When I set that ... oh my! I will have to go through and do some cleanup ... I don't like warnings! On the plus side, when I did this the first time it didn't take too long and none of them were great mysteries, just an obvious and mechanical adjustment in each case. -- bkw
Re: [M100] Building VirtualT
On Thu, Mar 26, 2020 at 6:44 PM Ken Pettit wrote: > Hey Brian, > > No, I didn't get any of these warnings, but then I didn't have the -Wall > flag set. When I set that ... oh my! I will have to go through and do > some cleanup ... I don't like warnings! > > Ken > > Don't ask, don't tell :-) sprintf at least is inherently dangerous and should never be used. Should always use snprintf so you're committing to a certain buffer size. -- John.
Re: [M100] Building VirtualT
Hey Brian, No, I didn't get any of these warnings, but then I didn't have the -Wall flag set. When I set that ... oh my! I will have to go through and do some cleanup ... I don't like warnings! Ken On 3/26/20 6:40 PM, Brian K. White wrote: On 3/25/20 10:27 AM, Ken Pettit wrote: Hey Guys, Okay, I have fixed this bug (in src/file.cpp). The de-tokenizer was not testing for quoted strings. I pushed the changes to the git repo here if anyone wants to pull it and compile prior to an official VT 1.8 release: git clone https://git.code.sf.net/p/virtualt/code virtualt Ken Don't you get a lot of these generated by your compiler? This is just a couple out of many from a fresh git pull. I didn't find these myself before, I just addressed each compiler warning until there weren't any more. I'll go through them again and see if sourceforge provides a way to submit patches back up like gitlab or github. src/m100emu.c: In function ‘check_installation’: src/m100emu.c:723:39: warning: ‘%s’ directive writing up to 255 bytes into a region of size 240 [-Wformat-overflow=] 723 | sprintf(localpath, "No ROM file for %s", errors); | ^~ ~~ In file included from /usr/include/stdio.h:867, from src/m100emu.c:32: /usr/include/x86_64-linux-gnu/bits/stdio2.h:36:10: note: ‘__builtin___sprintf_chk’ output between 17 and 272 bytes into a destination of size 256 36 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1, | ^~ 37 | __bos (__s), __fmt, __va_arg_pack ()); | ~ I also get this, which is probably from me using the latest fltk. But the changes I made for that apparently didn't break building with the older versions since Keven Becker said he just used the distro supplied package. Linking virtualt /usr/bin/ld: obj/remote.o: in function `key_delay()': remote.cpp:(.text+0x8f7): undefined reference to `fl_wait(double)' /usr/bin/ld: remote.cpp:(.text+0x927): undefined reference to `fl_wait(double)' /usr/bin/ld: obj/remote.o: in function `cmd_step(ServerSocket&, std::__cxx11::basic_string, std::allocator >&)': remote.cpp:(.text+0x3279): undefined reference to `fl_wait(double)' /usr/bin/ld: obj/remote.o: in function `cmd_step_over(ServerSocket&, std::__cxx11::basic_string, std::allocator >&)': remote.cpp:(.text+0x3577): undefined reference to `fl_wait(double)' /usr/bin/ld: remote.cpp:(.text+0x3639): undefined reference to `fl_wait(double)' /usr/bin/ld: obj/remote.o:remote.cpp:(.text+0xb066): more undefined references to `fl_wait(double)' follow collect2: error: ld returned 1 exit status make: *** [GNUmakefile:124: virtualt] Error 1 Assuming sourceforge provides a way to submit merge requests I'll do that shortly.
Re: [M100] Building VirtualT
On 3/25/20 10:27 AM, Ken Pettit wrote: Hey Guys, Okay, I have fixed this bug (in src/file.cpp). The de-tokenizer was not testing for quoted strings. I pushed the changes to the git repo here if anyone wants to pull it and compile prior to an official VT 1.8 release: git clone https://git.code.sf.net/p/virtualt/code virtualt Ken Don't you get a lot of these generated by your compiler? This is just a couple out of many from a fresh git pull. I didn't find these myself before, I just addressed each compiler warning until there weren't any more. I'll go through them again and see if sourceforge provides a way to submit patches back up like gitlab or github. src/m100emu.c: In function ‘check_installation’: src/m100emu.c:723:39: warning: ‘%s’ directive writing up to 255 bytes into a region of size 240 [-Wformat-overflow=] 723 | sprintf(localpath, "No ROM file for %s", errors); | ^~ ~~ In file included from /usr/include/stdio.h:867, from src/m100emu.c:32: /usr/include/x86_64-linux-gnu/bits/stdio2.h:36:10: note: ‘__builtin___sprintf_chk’ output between 17 and 272 bytes into a destination of size 256 36 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1, | ^~ 37 | __bos (__s), __fmt, __va_arg_pack ()); | ~ I also get this, which is probably from me using the latest fltk. But the changes I made for that apparently didn't break building with the older versions since Keven Becker said he just used the distro supplied package. Linking virtualt /usr/bin/ld: obj/remote.o: in function `key_delay()': remote.cpp:(.text+0x8f7): undefined reference to `fl_wait(double)' /usr/bin/ld: remote.cpp:(.text+0x927): undefined reference to `fl_wait(double)' /usr/bin/ld: obj/remote.o: in function `cmd_step(ServerSocket&, std::__cxx11::basic_string, std::allocator >&)': remote.cpp:(.text+0x3279): undefined reference to `fl_wait(double)' /usr/bin/ld: obj/remote.o: in function `cmd_step_over(ServerSocket&, std::__cxx11::basic_string, std::allocator >&)': remote.cpp:(.text+0x3577): undefined reference to `fl_wait(double)' /usr/bin/ld: remote.cpp:(.text+0x3639): undefined reference to `fl_wait(double)' /usr/bin/ld: obj/remote.o:remote.cpp:(.text+0xb066): more undefined references to `fl_wait(double)' follow collect2: error: ld returned 1 exit status make: *** [GNUmakefile:124: virtualt] Error 1 Assuming sourceforge provides a way to submit merge requests I'll do that shortly. -- bkw
