checks: Use of INFINITY and NAN instead of divisions

[neteler]

• use of INFINITY (1/0 = INFINITY) rather than only division by zero (this is supported by gcc and other compilers but not on Windows)
• use of NAN (0/0 = NAN) rather than only division by zero

Extracted from WIP PR #289

TODO: not sure about the changes in "raster/r.in.lidar/point_binning.c", taken from #289

In preparation for CMake support.

[neteler]

not sure about the changes in "raster/r.in.lidar/point_binning.c", taken from #289

CI fails here:

 gcc  -std=gnu99 -fPIC -Wall -Wno-error=maybe-uninitialized -Werror  -I/home/runner/work/grass/grass/dist.x86_64-pc-linux-gnu/include -I/home/runner/work/grass/grass/dist.x86_64-pc-linux-gnu/include    -DPACKAGE=\""grasslibs"\"   -I/home/runner/work/grass/grass/dist.x86_64-pc-linux-gnu/include -I/home/runner/work/grass/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"lib/raster3d\" -o OBJ.x86_64-pc-linux-gnu/mask.o -c mask.c
mask.c: In function ‘Rast3d_mask_tile’:
mask.c:317:20: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
  317 |             tile = (int*) + xLength;
      |                    ^
mask.c:319:16: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
  319 |         tile = (int*) + yLength;
      |                ^
cc1: all warnings being treated as errors
make[3]: *** [../../include/Make/Compile.make:32: OBJ.x86_64-pc-linux-gnu/mask.o] Error 1

[nilason]

This is a welcome change, adding INFINITY and NAN (both being C99 feats)!

As I see it the changes to the two files:

raster/r.in.lidar/point_binning.c

lib/raster3d/mask.c

are not related to INFINITY nor NAN.

coming from commits named void* arithmetic (GCC extension) is not allowed in msvc:
rkanavath@54116bb
rkanavath@ba30799

They can therefore be dropped from this PR.

[neteler]

Remaining error:

gcc  -std=gnu11 -fPIC -Wall -Wno-error=maybe-uninitialized -Werror  -I/home/runner/work/grass/grass/dist.x86_64-pc-linux-gnu/include -I/home/runner/work/grass/grass/dist.x86_64-pc-linux-gnu/include   -fopenmp -DPACKAGE=\""grassmods"\"   -I/home/runner/work/grass/grass/dist.x86_64-pc-linux-gnu/include -I/home/runner/work/grass/grass/dist.x86_64-pc-linux-gnu/include -DRELDIR=\"raster/r.univar\" -o OBJ.x86_64-pc-linux-gnu/r.univar_main.o -c r.univar_main.c
r.univar_main.c: In function ‘main’:
r.univar_main.c:168:21: error: overflow in conversion from ‘float’ to ‘CELL’ {aka ‘int’} changes value from ‘+QNaNf’ to ‘0’ [-Werror=overflow]
  168 |     zone_info.min = NAN;  /* set to nan as default */
      |                     ^~~
r.univar_main.c:169:21: error: overflow in conversion from ‘float’ to ‘CELL’ {aka ‘int’} changes value from ‘+QNaNf’ to ‘0’ [-Werror=overflow]
  169 |     zone_info.max = NAN;  /* set to nan as default */
      |                     ^~~
cc1: all warnings being treated as errors

What to do with that? (direct PR edits welcome)

[nilason]

Ohh, I found another inf in r.series:

grass/raster/r.series/main.c

Line 235 in e8f26dd

lo = -1.0 / 0.0; /* -inf */

[nilason]

Just realised there are tests in configure for this:

grass/aclocal.m4

Lines 303 to 324 in bcf83ad

	dnl checks for complete floating-point support (infinity, NaN)
	define(LOC_FP_TEST,[
	#include <float.h>
	int main(void) {
	double one = 1.0;
	double zero = 0.0;
	if (one/zero > DBL_MAX) /* infinity */
	if (zero/zero != zero/zero) /* NaN */
	return 0;
	return 1;
	}
	])
	AC_DEFUN([LOC_CHECK_FP_INF_NAN],[
	AC_MSG_CHECKING([for full floating-point support]$1)
	AC_RUN_IFELSE([AC_LANG_SOURCE([LOC_FP_TEST])],[ AC_MSG_RESULT(yes)
	$2],[ AC_MSG_RESULT(no)
	$3],[ AC_MSG_RESULT([unknown (cross-compiling)])
	$4
	])
	])

Let's consider how to handle them before merging this

[neteler]

I have attempted to update the PR formatting to match the clang-format changes in main, using

for i in $(gh pr view 2681 --json files --jq '.files.[].path') ; do clang-format -i $i ; done

But looking at the "Files changed" tab, these formatting changes are yet shown while I hoped for seeing only the relevant changes of this PR.
What's the trick? I guess a rebase step is needed? Since also other PRs are affected I'd like to learn how it is done in git.

[nilason]

I have attempted to update the PR formatting to match the clang-format changes in main, using

for i in $(gh pr view 2681 --json files --jq '.files.[].path') ; do clang-format -i $i ; done

But looking at the "Files changed" tab, these formatting changes are yet shown while I hoped for seeing only the relevant changes of this PR. What's the trick? I guess a rebase step is needed? Since also other PRs are affected I'd like to learn how it is done in git.

Even gave some good general advice in gdal ml, but they don't relate to existing PRs specifically.

Not being a git-magician myself, attempt to "merge main" turned hopeless, this is because you have to fix conflicts stepwise for each commit. As we in the end always squashing PRs to main, I see no reason (generally) not to squash-rebase.
Here's what I have done in some of my old PRs:

1. Apply clang-format to modified files in a new commit
2. Rebase interactively (git rebase -i HEAD~[no-of-commits-in-PR])
3. Either squash or fixup the commits in the PR to a single commit
4. git rebase main
5. assuming no conflicts: git push --force

[neteler]

2. Rebase interactively (git rebase -i HEAD~[no-of-commits-in-PR])

(just a small note to self)
Seems that the needed [no-of-commits-in-PR] is shown by:

git rev-list --count HEAD ^main
11

which corresponds to what the "Commits" tabs above shows. Useful to automate also the count step...

[neteler]

Pfew, seems it work out. Thanks for your git help, @nilason !

[neteler]

@nilason any objections to merge this PR? After your approval we got more changes :-)

[nilason]

@nilason any objections to merge this PR? After your approval we got more changes :-)

Please, go ahead and merge!