re: Issue https://github.com/Unidata/netcdf-c/issues/2573
The file type inferencer in libdispatch/dinference.c has a simple
forward inference mechanism so that the occurrence of certain mode
values in a URL fragment implies inclusion of additional mode values.
This kind of inference is notorious for leading to cycles if not
careful. Unfortunately, this occurred in the one in dinference.c.
This was fixed by providing a more complicated, but more reliable inference
mechanism.
## Misc. Other Changes
* Found and fixed a couple of memory leaks.
* There is a recent problem in building HDF4 support on github actions. Fixed by using the internal HDF4 xdr capability.
* Some filter-related code was not being properly ifdef'd with ENABLE_NCZARRA_FILTERS.
The test case nc_test4/tst_unknown.sh deletes and then restores
a filter in the plugins directory. The test nczarr_test/run_unknown.sh
also does this. However if both are running at the same time in a
parallel bit, they apparently can interfere and can cause a race
condition failure.
The solution is to suppress one of them. Since nczarr code
is more unstable, we need to run this test. So suppress the
corresponding test in nc_test4.
re: Issue https://github.com/Unidata/netcdf-c/issues/2551
Ryan May identified the use of a common scratch file (tmp.cdl)
across multiple test shell scripts in ncdump directory
and the nczarr_test directory.
This sometimes causes errors because of race conditions
between those scripts.
I renamed those common files to avoid the race condition. I
also did some further checking and found some additional,
similar conflicts and fixed those. Also did some minor cleanup
of unused files.
Tests fixed:
ncdump: run_back_comp_tests.sh tst_bom.sh tst_nccopy4.sh tst_nccopy5.sh
nczarr_test: git df master -- run_nccopyz.sh run_nczarr_fill.sh run_scalar.sh
I was getting the following error while compiling:
```
netcdf-c/libnczarr/zutil.c:544:26: error: called object 'strlen' is not a function or function pointer
544 | if(dnamep) *dnamep = strdup(dname);
| ^~~~~~
netcdf-c/libnczarr/zutil.c:533:68: note: declared here
533 | ncz_nctype2dtype(nc_type nctype, int endianness, int purezarr, int strlen, char** dnamep)
| ~~~~^~~~~~
```
My interpretation is that strdup() is implemented as a macro
which calls strlen() the standard C function, and when that
macro is being substituted here the call to strlen tries
to "call" the integer variable named strlen.
Resolving this by renaming the integer variable to "len"
instead of "strlen", avoiding a conflict with a standard
C library function name.
The use of this function currently runs into problems with multiple definitions: once for each file including ncconfigure.h. Defining this as static rather than extern should hide the definitions from each other.
static inline would still be closer to the definition as a macro, but that requires a #define to work on all platforms (not all compilers have inline yet).
