Portability improvements, cleanup, and bug fixes

[johnsonjh]

• Portability improvements, cleanup, and bug fixes:
  • Add or fix support for building on Solaris, illumos, Linux/musl, NetBSD, OpenBSD, IBM AIX, IBM OS/400 (PASE), Cygwin, and Haiku, which weren't previously cleanly building.
  • Use pkg-config when available to determine CFLAGS and libraries.
  • Initialize some variables in supdupd.
  • Fix off-by-one error in supdup.
  • Suppress spurious error when Chaosnet bridge socket is missing.
  • Create README.md.
  • Cleanup Makefile.
  • Cleanup excess trailing whitespace characters.
  • Indent nested preprocessor directives with GNU Cppi.
  • Consistently use modern preprocessor syntax.
  • Properly detect bad ports (negative or >65535).
  • Fix non-ANSI function declaration (put_newline).
  • Add *.ln (Lint) files, supdupd, and compile_commands.json to .gitignore.
  • Create .gitattributes.
  • Ensure file handle is valid (non-negative) before closing.
  • Correct various spelling errors.

• Tested build under Oracle Solaris, OpenIndiana illumos, Linux/musl, Linux/glibc, IBM AIX, IBM OS/400 (PASE), Haiku, FreeBSD, OpenBSD, NetBSD, Cygwin, and Apple macOS.

• Compilation tested and working with PCC, GCC, Clang, Xcode, IBM XL C, IBM Open XL C, Oracle Studio C, NVIDIA HPC SDK C, Portland Group C, and DMD ImportC.

• Passes Cppcheck and Clang Analyzer.

• Resolves GitHub Issues:
  • Closes #25
  • Closes #35
  • Closes #38

Signed-off-by: Jeffrey H. Johnson <[email protected]>

[johnsonjh]

@ams

About AIX, XCurses (Extended Curses, in AIX 7 base) does work, and can be built as follows with this PR applied and including "curses.h" instead of "ncurses.h" in supdup.c:

$ env CC="gcc-12" gmake NCURSES_LIBS="-lxcurses" EXTRA_LDFLAGS=" "
gcc-12 -D_ALL_SOURCE -I/opt/freeware/include -g -Wall   -c -o supdup.o supdup.c
gcc-12 -D_ALL_SOURCE -I/opt/freeware/include -g -Wall   -c -o charmap.o charmap.c
gcc-12 -D_ALL_SOURCE -I/opt/freeware/include -g -Wall   -c -o tcp.o tcp.c
gcc-12 -D_ALL_SOURCE -I/opt/freeware/include -g -Wall   -c -o chaos.o chaos.c
gcc-12 -g -o supdup supdup.o charmap.o tcp.o chaos.o -lxcurses

To answer your earlier question about why libcurses is required when using ncurses:

jhj@force ~/src/supdup $ env CC="gcc-12" gmake EXTRA_LDFLAGS=" "
gcc-12 -D_ALL_SOURCE -I/opt/freeware/include -g -Wall   -c -o supdup.o supdup.c
gcc-12 -D_ALL_SOURCE -I/opt/freeware/include -g -Wall   -c -o charmap.o charmap.c
gcc-12 -D_ALL_SOURCE -I/opt/freeware/include -g -Wall   -c -o tcp.o tcp.c
gcc-12 -D_ALL_SOURCE -I/opt/freeware/include -g -Wall   -c -o chaos.o chaos.c
gcc-12 -g -o supdup supdup.o charmap.o tcp.o chaos.o -L/opt/freeware/lib64 -lncurses
ld: 0711-317 ERROR: Undefined symbol: cur_term
ld: 0711-317 ERROR: Undefined symbol: .tputs
ld: 0711-317 ERROR: Undefined symbol: .setupterm
ld: 0711-317 ERROR: Undefined symbol: .tparm
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
collect2: error: ld returned 8 exit status
gmake: *** [GNUmakefile:44: supdup] Error 1

I still think we should require ncurses on AIX. We use ncurses on every other platform, and ncurses is usually integrated with pkg-config so it's easier to get the proper cflags and ldflags automatically.

Adding more complexity in the makefile to avoid requiring ncurses to be installed on AIX isn't a great tradeoff since ncurses is packaged by IBM, and if it's installed, everything works on AIX with a simple "gmake". If ncurses isn't installed, the error is also obvious.

Everything is also working with IBM's proprietary compilers in the latest commit, both 32- and 64-bit:

I've actually tested both V16 (XL) and V17 (Open XL) successfully.

[johnsonjh]

Also, I'm going to drop defaulting -g -Wall. If users want that they can easily adjust the CFLAGS, and it will unbreak building with proprietary compilers like Oracle Studio and IBM XL C, that don't use GNU compatible command invocations.

Squashing.

[johnsonjh]

[Moved to GitHub Issue #39.]

[bscottm]

@larsbrinkhoff: Is this going to get integrated?

[larsbrinkhoff]

@bscottm, I think so, but there was some discussion and I'm not sure everything was resolved. I'll take a look now.

[johnsonjh]

I left some comments about things that I'd like to see changed.

I'll get to this in the next day or two!

[ams]

Maybe we should get this in as is, since it contains lots of good changes. And any other fixes can be done in a different PR?

[johnsonjh]

Maybe we should get this in as is, since it contains lots of good changes. And any other fixes can be done in a different PR?

It will probably be easier to not mess with the whitespace here (rather than undo those changes later). Give me a few days to get around to it. Sorry, I forgot about it awhile before!

[larsbrinkhoff]

Maybe we should get this in as is, since it contains lots of good changes. And any other fixes can be done in a different PR?

I think this is the wrong approach. "Fix later" often becomes "fix never". A pull request should be cleaned up before merging. If it seems to take too long, or is too much work, maybe open a new pull request with only the good commits.

[johnsonjh]

I'll be able to work on it this weekend.

[ams]

Maybe we should get this in as is, since it contains lots of good changes. And any other fixes can be done in a different PR?

I think this is the wrong approach. "Fix later" often becomes "fix never". A pull request should be cleaned up before merging. If it seems to take too long, or is too much work, maybe open a new pull request with only the good commits.

There is also the other side of the coin, that continuously fixing minor points here and there it will never get merged because the person doing the work runs out of steam. Many of the changes here are good ones, some are more of minute importance, and some are just why. Splitting it up sounds like a good idea.

[larsbrinkhoff]

Thanks!