Lots of gcc compiler warnings on NetBSD

[SirWumpus]

Is there an existing issue for this?

• [X] I have searched for existing issues and did not find anything like it

Describe the bug

NetBSD 10.0 gcc (nb3 20231008) 10.5.0 gmake GNU Make 4.4.1

gmake MAKE=gmake clean all

Produces many compiler warnings.

What you expect

A clean build without compiler warnings. Warnings can be indicators of potential errors.

Environment

- OS:  NetBSD 10.0
- Device: guest VM on Windows VirtualBox
- Compiler: gcc (nb3 20231008) 10.5.0 
- Make: gmake - GNU Make 4.4.1

bug_report.sh output

bug-report.20240625.154037.txt

Anything else?

I hate bug report templates.

[xexyl]

Is there an existing issue for this?

• [x] I have searched for existing issues and did not find anything like it

Describe the bug

NetBSD 10.0 gcc (nb3 20231008) 10.5.0 gmake GNU Make 4.4.1

gmake MAKE=gmake clean all

Produces many compiler warnings.

What you expect

A clean build without compiler warnings. Warnings can be indicators of potential errors.

Environment

- OS:  NetBSD 10.0
- Device: guest VM on Windows VirtualBox
- Compiler: gcc (nb3 20231008) 10.5.0 
- Make: gmake - GNU Make 4.4.1

bug_report.sh output

bug-report.20240625.154037.txt

See my comment in your other issue. One can be ignored and the other main one is likely problematic to try and fix as it is (I believe) a typedef and that will vary from system to system as I am sure you know.

Anything else?

I hate bug report templates.

Alas some people find them easier and it can make it easier to go through.

[xexyl]

And I see something in the bug report that's kind of weird.

## RUNNING: make V=@ S=@ Q= E=@ I= Q_V_OPTION=1 INSTALL_V='-v' MAKE_CD_Q= test
make: "/home/achowe/git/ioccc_src/mkiocccentry/Makefile" line 124: Invalid line type
make: "/home/achowe/git/ioccc_src/mkiocccentry/Makefile" line 126: Invalid line type
make: "/home/achowe/git/ioccc_src/mkiocccentry/Makefile" line 128: Invalid line type
make: Fatal errors encountered -- cannot continue
make: stopped in /home/achowe/git/ioccc_src/mkiocccentry

but why when the script uses make and not a variable?

Would you please try:

gmake V=@ S=@ Q= E=@ I= Q_V_OPTION=1 INSTALL_V='-v' MAKE_CD_Q= test

and see if you get the same problem?

[SirWumpus]

I modified your command:

gmake V=@ S=@ Q= E=@ I= Q_V_OPTION=1 INSTALL_V='-v' MAKE_CD_Q= MAKE=gmake clean all test

And it fails.

cc -std=gnu11 -O3 -g3 -pedantic -Wall -Wextra  txzchk.c -c
In file included from /usr/include/ctype.h:100,
                 from txzchk.c:49:
txzchk.c: In function ‘parse_linux_txz_line’:
txzchk.c:998:27: warning: array subscript has type ‘char’ [-Wchar-subscripts]
  998 |     for ( ; *p && isdigit(*p) && *p != '/'; ) {
      |                           ^
txzchk.c:1017:27: warning: array subscript has type ‘char’ [-Wchar-subscripts]
 1017 |     for ( ; *p && isdigit(*p); ) {
      |                           ^
txzchk.c: In function ‘parse_bsd_txz_line’:
txzchk.c:1225:31: warning: array subscript has type ‘char’ [-Wchar-subscripts]
 1225 |     for (; p && *p && isdigit(*p); ) {
      |                               ^
txzchk.c:1244:31: warning: array subscript has type ‘char’ [-Wchar-subscripts]
 1244 |     for (; p && *p && isdigit(*p); ) {
      |                               ^
txzchk.c: In function ‘check_tarball’:
txzchk.c:1479:93: warning: implicit declaration of function ‘WEXITSTATUS’ [-Wimplicit-function-declaration]
 1479 |  warn("txzchk", "%s: %s %s failed with exit code: %d", tarball_path, fnamchk, tarball_path, WEXITSTATUS(exit_code));
      |                                                                                             ^~~~~~~~~~~
cc -std=gnu11 -O3 -g3 -pedantic -Wall -Wextra  txzchk.o soup/soup.a jparse/jparse.a dyn_array/dyn_array.a dbg/dbg.a -o txzchk
ld: txzchk.o: in function `check_tarball':
/home/achowe/git/ioccc_src/mkiocccentry/txzchk.c:1479: undefined reference to `WEXITSTATUS'
ld: /home/achowe/git/ioccc_src/mkiocccentry/txzchk.c:1586: undefined reference to `WEXITSTATUS'
gmake: *** [Makefile:448: txzchk] Error 1

[xexyl]

Okay I think I know why the compilation is failing.

It seems I forgot to include sys/wait.h there. I can take care of that now. Then when it's merged hopefully that part will work. In the meantime maybe you could try adding to txzchk.c includes:

#include <sys/wait.h>   /* for WEXITSTATUS() */

and retry. Then let me know if that solves it.

[xexyl]

Okay I think I know why the compilation is failing.

It seems I forgot to include sys/wait.h there. I can take care of that now. Then when it's merged hopefully that part will work. In the meantime maybe you could try adding to txzchk.c includes:

#include <sys/wait.h>   /* for WEXITSTATUS() */

and retry. Then let me know if that solves it.

UPDATE 0

Committed a bit ago: https://github.com/ioccc-src/mkiocccentry/pull/877/commits/838959576da5f8c65f9237762a1725684b8fb51b.

But if you add that line (if you're able to do so before the merge) and try the command and show the output it might be good. The warnings can be taken care of in time but might be better to see if we can get it to compile under your system.

[SirWumpus]

Tail of output once #include <sts/wait.h> added ...

PASSED: test_ioccc/txzchk_test.sh

RUNNING: test_ioccc/chkentry_test.sh

test_ioccc/chkentry_test.sh -v 1 -d ./test_ioccc/test_JSON -c ./chkentry
test_ioccc/chkentry_test.sh: debug[1]: -v: 1
test_ioccc/chkentry_test.sh: debug[1]: -D: 0
test_ioccc/chkentry_test.sh: debug[1]: -J: 0
test_ioccc/chkentry_test.sh: debug[1]: -q: false
test_ioccc/chkentry_test.sh: debug[1]: chkentry: ./chkentry
test_ioccc/chkentry_test.sh: debug[1]: all tests PASSED

PASSED: test_ioccc/chkentry_test.sh
test_ioccc: PASSED: ioccc_test.sh

test_ioccc: make test ending
gmake[1]: Leaving directory '/home/achowe/git/ioccc_src/mkiocccentry/test_ioccc'

mkiocccentry: make test ending

[xexyl]

And I see something in the bug report that's kind of weird.

## RUNNING: make V=@ S=@ Q= E=@ I= Q_V_OPTION=1 INSTALL_V='-v' MAKE_CD_Q= test
make: "/home/achowe/git/ioccc_src/mkiocccentry/Makefile" line 124: Invalid line type
make: "/home/achowe/git/ioccc_src/mkiocccentry/Makefile" line 126: Invalid line type
make: "/home/achowe/git/ioccc_src/mkiocccentry/Makefile" line 128: Invalid line type
make: Fatal errors encountered -- cannot continue
make: stopped in /home/achowe/git/ioccc_src/mkiocccentry

but why when the script uses make and not a variable?

Would you please try:

gmake V=@ S=@ Q= E=@ I= Q_V_OPTION=1 INSTALL_V='-v' MAKE_CD_Q= test

and see if you get the same problem?

Oh of course. I know why. It's because of the Makefile itself. Well that's something that might be worth changing indeed.

[xexyl]

Tail of output once #include <sts/wait.h> added ...

PASSED: test_ioccc/txzchk_test.sh

RUNNING: test_ioccc/chkentry_test.sh

test_ioccc/chkentry_test.sh -v 1 -d ./test_ioccc/test_JSON -c ./chkentry
test_ioccc/chkentry_test.sh: debug[1]: -v: 1
test_ioccc/chkentry_test.sh: debug[1]: -D: 0
test_ioccc/chkentry_test.sh: debug[1]: -J: 0
test_ioccc/chkentry_test.sh: debug[1]: -q: false
test_ioccc/chkentry_test.sh: debug[1]: chkentry: ./chkentry
test_ioccc/chkentry_test.sh: debug[1]: all tests PASSED

PASSED: test_ioccc/chkentry_test.sh
test_ioccc: PASSED: ioccc_test.sh

test_ioccc: make test ending
gmake[1]: Leaving directory '/home/achowe/git/ioccc_src/mkiocccentry/test_ioccc'

mkiocccentry: make test ending

Thanks! At least that is fixed (or will be once it's merged).

I wonder if running the bug reporting script would show something else now. I guess it will still have problems due to the situation of MAKE= make but at least you can now compile it by changing the variable (I think?).

[SirWumpus]

Heavy winds, possible rain coming, going to walk the puppy early. And before you ask... Clicquot

[xexyl]

Heavy winds, possible rain coming, going to walk the puppy early. And before you ask... Clicquot

Stay safe!

[xexyl]

Heavy winds, possible rain coming, going to walk the puppy early. And before you ask... Clicquot

Stay safe!

And thanks for the pictures!

[lcn2]

With the most recent commits, @SirWumpus, how do things look for NetBSD?

UPDATE 0

Are we ready to close this issue, or are there other warnings under NetBSD that need to be addressed ?

[SirWumpus]

Looks much better. Only warnings remaining pertain to format strings and their arguments.

bug-report.20240626.054930.txt build.log

[xexyl]

Looks much better. Only warnings remaining pertain to format strings and their arguments.

bug-report.20240626.054930.txt build.log

I'm not sure if everything is okay though. Look at this in the log:

#################################
# SECTION 3: COMPILATION CHECKS #
#################################

## RUNNING: make V=@ S=@ Q= E=@ I= Q_V_OPTION=1 INSTALL_V='-v' MAKE_CD_Q= clobber
make: "/home/achowe/git/ioccc_src/mkiocccentry/Makefile" line 123: Invalid line type
make: "/home/achowe/git/ioccc_src/mkiocccentry/Makefile" line 125: Invalid line type
make: "/home/achowe/git/ioccc_src/mkiocccentry/Makefile" line 127: Invalid line type
make: Fatal errors encountered -- cannot continue
make: stopped in /home/achowe/git/ioccc_src/mkiocccentry
./bug_report.sh: ERROR: make V=@ S=@ Q= E=@ I= Q_V_OPTION=1 INSTALL_V='-v' MAKE_CD_Q= clobber FAILED WITH EXIT CODE 1: NEW EXIT_CODE: 41
### ISSUE DETECTED: make V=@ S=@ Q= E=@ I= Q_V_OPTION=1 INSTALL_V='-v' MAKE_CD_Q= clobber returned 1
## OUTPUT OF make V=@ S=@ Q= E=@ I= Q_V_OPTION=1 INSTALL_V='-v' MAKE_CD_Q= clobber ABOVE

## RUNNING: make V=@ S=@ Q= E=@ I= Q_V_OPTION=1 INSTALL_V='-v' MAKE_CD_Q= all
make: "/home/achowe/git/ioccc_src/mkiocccentry/Makefile" line 123: Invalid line type
make: "/home/achowe/git/ioccc_src/mkiocccentry/Makefile" line 125: Invalid line type
make: "/home/achowe/git/ioccc_src/mkiocccentry/Makefile" line 127: Invalid line type
make: Fatal errors encountered -- cannot continue
make: stopped in /home/achowe/git/ioccc_src/mkiocccentry
./bug_report.sh: ERROR: make V=@ S=@ Q= E=@ I= Q_V_OPTION=1 INSTALL_V='-v' MAKE_CD_Q= all FAILED WITH EXIT CODE 1: NEW EXIT_CODE: 42
### ISSUE DETECTED: make V=@ S=@ Q= E=@ I= Q_V_OPTION=1 INSTALL_V='-v' MAKE_CD_Q= all returned 1
## OUTPUT OF make V=@ S=@ Q= E=@ I= Q_V_OPTION=1 INSTALL_V='-v' MAKE_CD_Q= all ABOVE

## RUNNING: make V=@ S=@ Q= E=@ I= Q_V_OPTION=1 INSTALL_V='-v' MAKE_CD_Q= test
make: "/home/achowe/git/ioccc_src/mkiocccentry/Makefile" line 123: Invalid line type
make: "/home/achowe/git/ioccc_src/mkiocccentry/Makefile" line 125: Invalid line type
make: "/home/achowe/git/ioccc_src/mkiocccentry/Makefile" line 127: Invalid line type
make: Fatal errors encountered -- cannot continue
make: stopped in /home/achowe/git/ioccc_src/mkiocccentry
./bug_report.sh: ERROR: make V=@ S=@ Q= E=@ I= Q_V_OPTION=1 INSTALL_V='-v' MAKE_CD_Q= test FAILED WITH EXIT CODE 1: NEW EXIT_CODE: 43
### ISSUE DETECTED: make V=@ S=@ Q= E=@ I= Q_V_OPTION=1 INSTALL_V='-v' MAKE_CD_Q= test returned 1
## OUTPUT OF make V=@ S=@ Q= E=@ I= Q_V_OPTION=1 INSTALL_V='-v' MAKE_CD_Q= test ABOVE

and so on.

In fact at the end, the summary:

One or more problems occurred:

    make V=@ S=@ Q= E=@ I= Q_V_OPTION=1 INSTALL_V='-v' MAKE_CD_Q= clobber non-zero exit code: 1
    make V=@ S=@ Q= E=@ I= Q_V_OPTION=1 INSTALL_V='-v' MAKE_CD_Q= all non-zero exit code: 1
    make V=@ S=@ Q= E=@ I= Q_V_OPTION=1 INSTALL_V='-v' MAKE_CD_Q= test non-zero exit code: 1
    make -C jparse V=@ S=@ Q= E=@ I= Q_V_OPTION=1 INSTALL_V='-v' MAKE_CD_Q= run_bison-v7 non-zero exit code: 1
    make -C jparse V=@ S=@ Q= E=@ I= Q_V_OPTION=1 INSTALL_V='-v' MAKE_CD_Q= run_flex-v7 non-zero exit code: 1
    make V=@ S=@ Q= E=@ I= Q_V_OPTION=1 INSTALL_V='-v' MAKE_CD_Q= all non-zero exit code: 1

Final exit code: 47

There were several failures though, some of which I noted above.

But if you are using GNU Make why is this happening? The Makefile does not use MAKE now and the script always used make so why is this happening? And yet ... the tools are being run okay! Something is funny here ..

[xexyl]

Looks much better. Only warnings remaining pertain to format strings and their arguments. bug-report.20240626.054930.txt build.log

I'm not sure if everything is okay though. Look at this in the log:

#################################
# SECTION 3: COMPILATION CHECKS #
#################################

## RUNNING: make V=@ S=@ Q= E=@ I= Q_V_OPTION=1 INSTALL_V='-v' MAKE_CD_Q= clobber
make: "/home/achowe/git/ioccc_src/mkiocccentry/Makefile" line 123: Invalid line type
make: "/home/achowe/git/ioccc_src/mkiocccentry/Makefile" line 125: Invalid line type
make: "/home/achowe/git/ioccc_src/mkiocccentry/Makefile" line 127: Invalid line type
make: Fatal errors encountered -- cannot continue
make: stopped in /home/achowe/git/ioccc_src/mkiocccentry
./bug_report.sh: ERROR: make V=@ S=@ Q= E=@ I= Q_V_OPTION=1 INSTALL_V='-v' MAKE_CD_Q= clobber FAILED WITH EXIT CODE 1: NEW EXIT_CODE: 41
### ISSUE DETECTED: make V=@ S=@ Q= E=@ I= Q_V_OPTION=1 INSTALL_V='-v' MAKE_CD_Q= clobber returned 1
## OUTPUT OF make V=@ S=@ Q= E=@ I= Q_V_OPTION=1 INSTALL_V='-v' MAKE_CD_Q= clobber ABOVE

## RUNNING: make V=@ S=@ Q= E=@ I= Q_V_OPTION=1 INSTALL_V='-v' MAKE_CD_Q= all
make: "/home/achowe/git/ioccc_src/mkiocccentry/Makefile" line 123: Invalid line type
make: "/home/achowe/git/ioccc_src/mkiocccentry/Makefile" line 125: Invalid line type
make: "/home/achowe/git/ioccc_src/mkiocccentry/Makefile" line 127: Invalid line type
make: Fatal errors encountered -- cannot continue
make: stopped in /home/achowe/git/ioccc_src/mkiocccentry
./bug_report.sh: ERROR: make V=@ S=@ Q= E=@ I= Q_V_OPTION=1 INSTALL_V='-v' MAKE_CD_Q= all FAILED WITH EXIT CODE 1: NEW EXIT_CODE: 42
### ISSUE DETECTED: make V=@ S=@ Q= E=@ I= Q_V_OPTION=1 INSTALL_V='-v' MAKE_CD_Q= all returned 1
## OUTPUT OF make V=@ S=@ Q= E=@ I= Q_V_OPTION=1 INSTALL_V='-v' MAKE_CD_Q= all ABOVE

## RUNNING: make V=@ S=@ Q= E=@ I= Q_V_OPTION=1 INSTALL_V='-v' MAKE_CD_Q= test
make: "/home/achowe/git/ioccc_src/mkiocccentry/Makefile" line 123: Invalid line type
make: "/home/achowe/git/ioccc_src/mkiocccentry/Makefile" line 125: Invalid line type
make: "/home/achowe/git/ioccc_src/mkiocccentry/Makefile" line 127: Invalid line type
make: Fatal errors encountered -- cannot continue
make: stopped in /home/achowe/git/ioccc_src/mkiocccentry
./bug_report.sh: ERROR: make V=@ S=@ Q= E=@ I= Q_V_OPTION=1 INSTALL_V='-v' MAKE_CD_Q= test FAILED WITH EXIT CODE 1: NEW EXIT_CODE: 43
### ISSUE DETECTED: make V=@ S=@ Q= E=@ I= Q_V_OPTION=1 INSTALL_V='-v' MAKE_CD_Q= test returned 1
## OUTPUT OF make V=@ S=@ Q= E=@ I= Q_V_OPTION=1 INSTALL_V='-v' MAKE_CD_Q= test ABOVE

and so on.

In fact at the end, the summary:

One or more problems occurred:

  make V=@ S=@ Q= E=@ I= Q_V_OPTION=1 INSTALL_V='-v' MAKE_CD_Q= clobber non-zero exit code: 1
  make V=@ S=@ Q= E=@ I= Q_V_OPTION=1 INSTALL_V='-v' MAKE_CD_Q= all non-zero exit code: 1
  make V=@ S=@ Q= E=@ I= Q_V_OPTION=1 INSTALL_V='-v' MAKE_CD_Q= test non-zero exit code: 1
  make -C jparse V=@ S=@ Q= E=@ I= Q_V_OPTION=1 INSTALL_V='-v' MAKE_CD_Q= run_bison-v7 non-zero exit code: 1
  make -C jparse V=@ S=@ Q= E=@ I= Q_V_OPTION=1 INSTALL_V='-v' MAKE_CD_Q= run_flex-v7 non-zero exit code: 1
  make V=@ S=@ Q= E=@ I= Q_V_OPTION=1 INSTALL_V='-v' MAKE_CD_Q= all non-zero exit code: 1

Final exit code: 47

There were several failures though, some of which I noted above.

But if you are using GNU Make why is this happening? The Makefile does not use MAKE now and the script always used make so why is this happening? And yet ... the tools are being run okay! Something is funny here ..

What's most bizarre is if the tools are executable they have obviously been compiled but exit code 47 is from running (a second time) make all. And we can see clearly there is an issue with the Makefile.

I'm not sure what shell you're using but can you do the equivalent of:

type -P make

just to be sure it's the GNU one? if not that would explain the problem and perhaps I can add an option to the script to specify the path of make(1). Maybe I should do that anyway actually ..

[xexyl]

I am not at the laptop now but when I am back I will finish updating the log for yesterday's fix and then make a pull request. After that I will update the bug report script so that you can specify which make(1) to use.

My guess is that is why the script is showing errors even though you can manually compile it.

Maybe I can make the script check first for gmake and use it if it exists. The help string and the man page can refer to this and also the new option. I think that will improve it and help out in the future.

[xexyl]

Almost done with the bug_report.sh update .. tested with bsdmake and it failed as expected (with the new -m option). Running it with gmake works as expected. Running it without the path it will try and find it as gmake first and then if that fails it'll go back to make.

I'll do a pull request soonish but I'll also attach the script here so you can try running it and see if it helps you. Stay tuned (not that I think you're an instrument .. :-) )!

[xexyl]

Okay would you please try this script in the meantime? See if the script can actually run the steps okay. It's a good change anyway but I still have to update the man page and then the changelog ... and I am not sure how long that'll take as I am very tired. I might try getting a bit more rest but I think I won't be able to if I'm honest. I know my body too well. Anyway try this please:

bug_report.sh.txt

Obviously remove the .txt: that's added because GitHub won't let you update .sh files ...

[xexyl]

Okay would you please try this script in the meantime? See if the script can actually run the steps okay. It's a good change anyway but I still have to update the man page and then the changelog ... and I am not sure how long that'll take as I am very tired. I might try getting a bit more rest but I think I won't be able to if I'm honest. I know my body too well. Anyway try this please:

bug_report.sh.txt

Obviously remove the .txt: that's added because GitHub won't let you update .sh files ...

Hopefully with commit 2698b30c047e9eb840acfdd39257c3d22360d443 things will be better for cases like yours. I'd appreciate your testing of it too of course, but now it will try for gmake before make and you can also change the path to anything you want, even /bin/echo if you wanted - not that that would be very helpful! :-)

[SirWumpus]

NetBSD

elf$ type gmake
gmake is /usr/pkg/bin/gmake
elf$

FreeBSD also has gmake, but installed I think in /usr/local/bin (not sure,need to start a VM).

Also some Linus distros might have bmake instead of bsdmake.

Makefiles should refer to ${MAKE} and scripts like bug_report.sh will need to automagically guess which make and where and offer an option to override. I'll test your updated script shortly.

[xexyl]

NetBSD

elf$ type gmake

gmake is /usr/pkg/bin/gmake

elf$

FreeBSD also has gmake, but installed I think in /usr/local/bin (not sure,need to start a VM).

Also some Linus distros might have bmake instead of bsdmake.

Makefiles should refer to ${MAKE} and scripts like bug_report.sh will need to automagically guess which make and where and offer an option to override. I'll test your updated script shortly.

I was after type on make to see if it went to gmake or not.

And yes bmake is actually referenced.

The update to the script should help though. Tries to find gmake and you can also specify the path to make now too.

[xexyl]

And yes please let me know how the update goes. I will be away for a little bit but how much more I can do today is another question. Not much time left I'm afraid.

[SirWumpus]

Find an air-con Tim Hortons (or "southern Canada" equivalent) with WiFi?

[xexyl]

Find an air-con Tim Hortons (or "southern Canada" equivalent) with WiFi?

Seeing me in such a place is as likely as seeing me eating citrus fruit I'm afraid which means it'll never happen. :-) For most people it would be a good suggestion except for the fact that my auntie has air con and WiFi and lives five minutes away. but I won't have my laptop with me. I suppose I could but I don't like to take it out and I also could only work on some things: not the website for instance as to do that I connect to my server .. which of course will be down.

Thanks for the suggestion though! The good thing about being at my auntie's place is as noted above the distance.

We are pondering, as I said, a bookshop for a bit - been too long since I've been to one but it's quite problematic even without the reasons I said as glasses + mask is not a nice thing. I said that but with hearing aids it's even more uncomfortable.

... still would like to be able to if we can. But it's in another city over and we might not even want to go that far. Right now (6:27) it's 18 C but the humidity is 81% which is insanity here .. unless it's raining. The bookshop won't be open for at least two hours but very likely three or 3 and a half hours and by that time it'll be 25 C. Okay not THAT bad and certainly not like we've had before but with the Sun hitting down it's quite bad for me and it would only get hotter. Plus the humidity.

I sometimes do wear a mask and my hearing aids too but it's not nice. And ever since that surgery and ever slow recovery I have a problem being out. Without getting into 'unpleasant details' that's all I'll say. I hope that is resolved soon as it's making sleep really hard too! :(

On the other hand I guess if I had to wake up at stupid o'clock today is the right day to do it .. as long as it doesn't happen again. Only earlier this year that changed from at least two years of it happening every day and lately it seems to be reversing :(

[xexyl]

Anyway please let me know how the script goes when you get a chance to test. I won't be able to make any fixes for very long (which likely means not until tomorrow at this point .. in under an hour power goes off) but I might be able to reply through the phone. Still undecided if I will take my reading glasses or not. I should as distance glasses are hard on my eyes when reading but I don't know if I will.

Hopefully the changes will help you get a proper test result though.

[SirWumpus]

That updated bug_report.sh appears to work fine now. bug-report.20240626.101844.txt

• type -P name is a bash-ism

• bash required to be installed (plus gmake) on Unix systems.

• For portability do you really want to require bash if the same can be done with a POSIX (Korn) shell? Allowing for bash can lead towards using non-POSIX features. Is that an acceptable choice?

[xexyl]

That updated bug_report.sh appears to work fine now. bug-report.20240626.101844.txt

I will have to look at it tomorrow. My eyes have been very sore and dry and looking at phones makes it worse. I just hope it's the poor sleep but time will tell. Thank you for testing!

• type -P name is a bash-ism

That is true but we rely on it. See below.

• bash required to be installed (plus gmake) on Unix systems.

• For portability do you really want to require bash if the same can be done with a POSIX (Korn) shell? Allowing for bash can lead towards using non-POSIX features. Is that an acceptable choice?

All the other scripts rely on it too and it's on many more systems than the fabulous ksh. But I only did it as I was asked.

Do you think @lcn2 that will we should change it? If so how?

As for GNU make this is actually in the FAQ of the website and I can't help that one.

Again thank you for testing!

[lcn2]

Find an air-con Tim Hortons (or "southern Canada" equivalent) with WiFi?

While once Tim's was an interesting cultural experience for a yank such as me, where crossing what is known as "Trudeau's ditch":

and visit a Tim Horton's (with or without the apostrophe 🤓).

Unfortunately it seems that after the US company who runs the so-called "Burger King" chain purchased Tim's, the general franchise appears to have gone "down hill".

There appears to be a few select outlets where a "Double Double" can be obtained without risking your gut and general constitution, you have to know which outlets are the better ones.

Still: late at night break or getting out of a snow storm, Tim's is an option - just not the option it once was.

Sorry (tm Canada 🇨🇦)

[lcn2]

... Thank you for testing!

Yes, thank you @SirWumpus

Some of us are fond of BSD (well, some of the variants) and worked on BSD back in the day when it was at Berkeley, so testing on it is appreciated.

• type -P name is a bash-ism

That is true but we rely on it. See below.

• bash required to be installed (plus gmake) on Unix systems.

• For portability do you really want to require bash if the same can be done with a POSIX (Korn) shell? Allowing for bash can lead towards using non-POSIX features. Is that an acceptable choice?

All the other scripts rely on it too and it's on many more systems than the fabulous ksh. But I only did it as I was asked.

Do you think @lcn2 that will we should change it? If so how?

As far as this mkiocccentry repo goes, we should strive to be somewhat more portable.

We say somewhat as there are limits:

• We don't need to support the v7 shell 🐚
• We don't need to support System III nor System V shell 😉
• And we certainly don't need to support the Eunice command line e 🤪

It is unfortunate that in a number of BSD-like systems, /bin/sh is a stripped down v7-like shell.

Trying to create a truly portable shell script is an art that is full of arcane elements: one that turns a sane shell 🐚 script into portable insanity 🤪. Just look at what the GNU configure has to try to do in the general shell script case as one mild example of portability complexity.

We do put the following "shbang" line at the top of all shell scripts in this mkiocccentry repo:

#!/usr/bin/env bash

So to run any of them one needs to have bash somewhere on $PATH. And given that too many BSD-like environments have a /bin/sh that is extremely back-reved (sometimes to a pre-POSIX level ‼️) that we don't want to assume that sh in the $PATH is useful.

We are very sympathetic to ksh. It was Landon Noll and David Korn who almost dual-handed fought a long fight against Steven Bourne and AT&T Summit folks to get the POSIX shell standard to some level of "reasonableness".

We don't see how we could do a reasonable "shbang" first line that doesn't just assume sh, given the lack of evolution of /bin/sh on some BSD-like systems.

Given that the shell scripts in this mkiocccentry repo use a "shbang" for bash, and that bash is supported and available on BSD, does it matter if we use type -P in the same shell script?

We ask all of the above is good humor and would appreciate any feedback folks might have.

OT

The bin tools for the IOCCC web site (as in the temp-test-ioccc repo) are strictly bash. However since the only the IOCCC judges need to use those tools, that restriction is OK.

[xexyl]

Find an air-con Tim Hortons (or "southern Canada" equivalent) with WiFi?

While once Tim's was an interesting cultural experience for a yank such as me, where crossing what is known as "Trudeau's ditch":

and visit a Tim Horton's (with or without the apostrophe 🤓)

Unfortunately it seems that after the US company who runs the so-called "Burger King" chain purchased Tim's, the general franchise appears to have gone "down hill".

There appears to be a few select outlets where a "Double Double" can be obtained without risking your gut and general constitution, you have to know which outlets are the better ones.

Still: late at night break or getting out of a snow storm, Tim's is an option - just not the option it once was.

Sorry (tm Canada 🇨🇦)

That is a picture of you, right?

Nice pictures either way.

Power outage for a few more hours. Just ordered pizza since we can't (or don't want to) open the refrigerator.

We're going to go get ice cream later on too. Or we plan to.

[lcn2]

That updated bug_report.sh appears to work fine now. bug-report.20240626.101844.txt

Thanks for the updated report, @SirWumpus.

@xexyl, there appears to be a few printf-ish format errors of the form:

./jparse.y:832:42: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘yy_size_t’ {aka ‘long unsigned int’} [-Wformat=]
  832 |      json_dbg(JSON_DBG_VVHIGH, __func__, "under json_number: yyleng: <%d>", jparse_get_leng(scanner));
      |                                          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  ~~~~~~~~~~~~~~~~~~~~~~~~
      |                                                                             |
      |                                                                             yy_size_t {aka long unsigned int}

Where, given that is being printed, a cast on the arg being printed would do just fine.

So that might be a good thing to do for your JSON parser.

[lcn2]

Allowing for bash can lead towards using non-POSIX features. Is that an acceptable choice?

Understood and yes.

We have moved the IOCCC beyond just POSIX, BTW. We think it was you who suggested we update the IOCCC rules and IOCCC guidelines to refer to the Single UNIX Specification instead of POSIX.

And while bash stuff like type -P is not in a standard, it doesn't have to be wholly standard.

There is an important difference between the environment needed to compile and run the mkiocccentry tool, and the environment in which a submission to the IOCCC runs in.

A submission to the IOCCC should focus on an Single UNIX Specification environment. So if someone uses a windows environment that supports Single UNIX Specification as a basis for their submission, that would be (hopefully) portable enough for those without such a windows environment to consider.

Such a windows person, however, would have to find a suitable non-windows environment in which to run the mkiocccentry application in order to package their submission. And that's probably a good thing as they could use that same system to test their IOCCC submission.

[SirWumpus]

Given that the shell scripts in this mkiocccentry repo use a "shbang" for bash, and that bash is supported and available on BSD, does it matter if we use type -P in the same shell script?

We ask all of the above is good humor and would appreciate any feedback folks might have.

My take on it is bash is fine if you can limit yourself to POSIX / ksh-isms and avoid using bash only features. That would allow for drop-in replacements.

NetBSD stock shells are

/bin/sh
/bin/csh
/bin/ksh

As I recall OpenBSD switched years ago to a default Korn shell for /bin/sh. I think FreeBSD is the odd one; root defaults to csh for BSD historical reasons, while users get Korn shell? Can'tbe sure of that last (don't have a current FreeBSD VM to start).

Now why NetBSD uses a pruned down /bin/sh I think is weird, /bin/sh and /bin/ksh don't differ that much in size.

     sh is the standard command interpreter for the system.  It is a re-
     implementation and extension of the Bourne shell.  This version has many
     features which make it appear similar in some respects to the Korn shell,
     but it is not a Korn shell clone (see ksh(1)).

Ugh! If they were worried about the size of /root, I would have made /bin/sh a hard link to ksh and avoided the extra nonsense and confusion.

One could continue to use bash and just set -o posix to be sure not avoid feature creep.

Its a hard choice and annoying that everyone thinks POSIX is a good thing then they turn around and add more cruft to tools (some good, lots bad). Defeats the purpose of being portable.

Sorry (I'm Canadian, not tm license for me) I go a little nuts about this topic.

[SirWumpus]

... refer to the Single UNIX Specification instead of POSIX.

Yep. Guilty.

[SirWumpus]

Back in the old days I remember trying to ensure my entries worked on as many platforms as possible with a variety of compilers.

These days with VMs I guess the argument can be made it that its fairly easy to test multiple platforms and one for submission. I just don't like the Linux overrun of the landscape.

[xexyl]

That updated bug_report.sh appears to work fine now. bug-report.20240626.101844.txt

Thanks for the updated report, @SirWumpus.

@xexyl, there appears to be a few printf-ish format errors of the form:

./jparse.y:832:42: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘yy_size_t’ {aka ‘long unsigned int’} [-Wformat=]
  832 |      json_dbg(JSON_DBG_VVHIGH, __func__, "under json_number: yyleng: <%d>", jparse_get_leng(scanner));
      |                                          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  ~~~~~~~~~~~~~~~~~~~~~~~~
      |                                                                             |
      |                                                                             yy_size_t {aka long unsigned int}

Where, given that is being printed, a cast on the arg being printed would do just fine.

So that might be a good thing to do for your JSON parser.

One problem with doing that: I believe they are typedefs and this means a cast might work for some systems but then trigger a warning on another. I know I have run into that very problem before.

Now if I see it in macOS tomorrow I can look at fixing it. Unfortunately I believe Rocky linux might not have a recent enough version of flex/bison. If that's so and it's not easy to manage it might be hard to fix.

But I can't check that until tomorrow. I believe I got it sorted for CentOS but I don't know now.

I really need to get the fedora box back up ...

Anyway let me know what you think and I can proceed tomorrow.

[lcn2]

That is a picture of you, right?

Yes.

[xexyl]

That is a picture of you, right?

Yes.

Thanks (and nice picture)!

[lcn2]

That updated bug_report.sh appears to work fine now. bug-report.20240626.101844.txt

Thanks for the updated report, @SirWumpus. @xexyl, there appears to be a few printf-ish format errors of the form:

./jparse.y:832:42: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘yy_size_t’ {aka ‘long unsigned int’} [-Wformat=]
  832 |      json_dbg(JSON_DBG_VVHIGH, __func__, "under json_number: yyleng: <%d>", jparse_get_leng(scanner));
      |                                          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  ~~~~~~~~~~~~~~~~~~~~~~~~
      |                                                                             |
      |                                                                             yy_size_t {aka long unsigned int}

Where, given that is being printed, a cast on the arg being printed would do just fine. So that might be a good thing to do for your JSON parser.

One problem with doing that: I believe they are typedefs and this means a cast might work for some systems but then trigger a warning on another. I know I have run into that very problem before.

Now if I see it in macOS tomorrow I can look at fixing it. Unfortunately I believe Rocky linux might not have a recent enough version of flex/bison. If that's so and it's not easy to manage it might be hard to fix.

But I can't check that until tomorrow. I believe I got it sorted for CentOS but I don't know now.

I really need to get the fedora box back up ...

Anyway let me know what you think and I can proceed tomorrow.

Fixed in commit ef79efc287a357d038d7736fed03ed0a640119c0

There is a new notice that needs to be fixed, however .. stay tuned.

[xexyl]

Allowing for bash can lead towards using non-POSIX features. Is that an acceptable choice?

Understood and yes.

We have moved the IOCCC beyond just POSIX, BTW. We think it was you who suggested we update the IOCCC rules and IOCCC guidelines to refer to the Single UNIX Specification instead of POSIX.

And while bash stuff like type -P is not in a standard, it doesn't have to be wholly standard.

There is an important difference between the environment needed to compile and run the mkiocccentry tool, and the environment in which a submission to the IOCCC runs in.

A submission to the IOCCC should focus on an Single UNIX Specification environment. So if someone uses a windows environment that supports Single UNIX Specification as a basis for their submission, that would be (hopefully) portable enough for those without such a windows environment to consider.

Such a windows person, however, would have to find a suitable non-windows environment in which to run the mkiocccentry application in order to package their submission. And that's probably a good thing as they could use that same system to test their IOCCC submission.

Also on the subject of BSD. I also have fond memories of: I only moved to linux because it has a vastly superior libc and it was proving to be a problem with one of the projects I work on - had to put a lot of ifdefs and changing printf formatting and many other things.

Some of what we relied on is linux specific but a lot of it was simply a lacking libc.

Anyway as far as mkiocccentry and BSD. There was actually discussion about this. I brought up the concern of portability with some implementations of tar as an example but the idea which is in the comment I am replying to was how it went (in one case namely OpenBSD it was thought that that's the fault of BSD itself but I am vague on specifics and I don't want to disparage anyone either).

And as far as GNU make goes, like I said it's in the FAQ. Sorry .. don't know which one. Typing this on the phone. Power back up but haven't turned UPSes and server and everything up just yet. About to though.

Personally I am kind of mixed but I also think bash is quite available so it probably shouldn't be a problem.

[xexyl]

That updated bug_report.sh appears to work fine now. bug-report.20240626.101844.txt

Thanks for the updated report, @SirWumpus.

@xexyl, there appears to be a few printf-ish format errors of the form:

./jparse.y:832:42: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘yy_size_t’ {aka ‘long unsigned int’} [-Wformat=]

  832 |      json_dbg(JSON_DBG_VVHIGH, __func__, "under json_number: yyleng: <%d>", jparse_get_leng(scanner));

      |                                          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  ~~~~~~~~~~~~~~~~~~~~~~~~

      |                                                                             |

      |                                                                             yy_size_t {aka long unsigned int}

Where, given that is being printed, a cast on the arg being printed would do just fine.

So that might be a good thing to do for your JSON parser.

One problem with doing that: I believe they are typedefs and this means a cast might work for some systems but then trigger a warning on another. I know I have run into that very problem before.

Now if I see it in macOS tomorrow I can look at fixing it. Unfortunately I believe Rocky linux might not have a recent enough version of flex/bison. If that's so and it's not easy to manage it might be hard to fix.

But I can't check that until tomorrow. I believe I got it sorted for CentOS but I don't know now.

I really need to get the fedora box back up ...

Anyway let me know what you think and I can proceed tomorrow.

Fixed in commit ef79efc287a357d038d7736fed03ed0a640119c0

There is a new notice that needs to be fixed, however .. stay tuned.

Will check tomorrow. Thanks for addressing it! About to boot things up. Won't be at a computer with a GUI until tomorrow so I am still kind of limited with replying and checking things but I am sure it's fine. I will let you know if I encounter anything.

I trust you updated the version and updated the test files?

[SirWumpus]

... bash is quite available so it probably shouldn't be a problem.

But there people (me, myself, and I) who don't want to pollute their systems by installing lots of extra tools, libs, etc. if at all possible. Similarly there maybe systems that choose or have to be kept lean (Raspberry Pis? I've never played with one).

Granted 99% IOCCC participants will run on personal work boxes, which probably have sufficient room and the users probably won't have our delicate sensibilities about portability and feature creep.

[lcn2]

I trust you updated the version and updated the test files?

As the fix was a simply cast on 4 debug statements to minimize warnings where no functionality changed, we didn't see a need to rev the version on the parser.

The other fix is changing bug_report.sh and so that version will change.

Fixed the gmake not found report in commit df02422a4913ebfee52f0352aa9ab97b614307be.

[lcn2]

So, @SirWumpus, given all of the above, it appears that nearly all, if not all compile warnings have been addressed.

We do appreciate the time you took to report these compile issues.

If that is true, shall we close this issue?

[xexyl]

... bash is quite available so it probably shouldn't be a problem.

But there people (me, myself, and I) who don't want to pollute their systems by installing lots of extra tools, libs, etc. if at all possible. Similarly there maybe systems that choose or have to be kept lean (Raspberry Pis? I've never played with one).

That is something you will have to take up with the judges I am afraid.

Granted 99% IOCCC participants will run on personal work boxes, which probably have sufficient room and the users probably won't have our delicate sensibilities about portability and feature creep.

Indeed. It doesn't hurt really to have those others anyway as it's helpful to test.

I would argue that macOS is partly based on BSD (and of course NextSTEP) and it works fine but I won't because I know it's expected to, it's not necessarily that simple and because Landon and I both have a MacBook Pro (with the M1 Pro chip .. not sure of the names now but I got the maximum one and have no intention of upgrading until I have no choice) so it obviously would work with macOS.

Anyway at least you can get it to work. I do understand this idea in other things though so I am quite sympathetic. And I might add that it's highly likely you are actually more tolerant than I am about using things you would rather not have to. Not that I won't if I have no choice but I might not always take it well.

To put that simply that is a compliment and saying that you are probably better than me!

But I am glad that the changes we have made help out at least! Thanks for uncovering the problem with the missing include and the missing functionality in the bug report script!

If there's anyway I can help more please do feel free to ask! I do not mind at all.

[xexyl]

I trust you updated the version and updated the test files?

As the fix was a simply cast on 4 debug statements to minimize warnings where no functionality changed, we didn't see a need to rev the version on the parser.

Fair enough. You have had me update version for something that simple before which is why I updated the txzchk version for the simple additional include.

The other fix is changing bug_report.sh and so that version will change.

Fixed the gmake not found report in commit df02422a4913ebfee52f0352aa9ab97b614307be.

Is there a need to update the version a second time today? Well I guess it might be good depending on what changed. But I did update it today fwiw.

[xexyl]

So, @SirWumpus, given all of the above, it appears that nearly all, if not all compile warnings have been addressed.

We do appreciate the time you took to report these compile issues.

If that is true, shall we close this issue?

I ALSO really appreciate it too btw!

[xexyl]

Interesting update to my fixes!

Thanks. I will look at it better at the computer tomorrow.

Off again!

[SirWumpus]

Ok. Have just tested the rebuilding of the tools and test. It appears to look good. Here's the output: bug-report.20240626.182259.txt build.log

If after reviewing this they look clean, I think this issue can be closed.

[SirWumpus]

We do appreciate the time you took to report these compile issues.

You know me. I aim to please and bug hunt equally. If it makes it better, then its time well spent. Plus testing across more platforms, the better.