mirror/netcdf-c
2
0
Fork 0
mirror of https://github.com/Unidata/netcdf-c.git synced 2025-02-11 16:40:36 +08:00
Code Issues Packages Projects Releases Wiki Activity
3bcdb5fbf1
netcdf-c/ncgen/ncgeny.c

3593 lines
112 KiB
C
Raw Normal View History

1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
/* A Bison parser, made by GNU Bison 3.0.4. */
Resolves Github issue https://github.com/Unidata/netcdf-c/issues/349. Update utf8proc.[ch] to use the version now maintained by the Julia Language project (https://github.com/JuliaLang/utf8proc/blob/master/LICENSE.md). The license for the previous version was unacceptable for the Debian and Ubuntu release systems. The new version both updates the code and addresses the license issue. It turns out that the utf8proc software we are using was turned over to the Julia Language developers and the license terms changed to allow modification. (https://github.com/JuliaLang/utf8proc/blob/master/LICENSE.md). So the fix here is as follows: 1. Wrap the library with a fixed interface: libdispatch/dutf8.c and include/ncutf8.h. 2. Replace the existing utf8proc code with the new version from https://github.com/JuliaLang/utf8proc. 3. Add a couple more test cases: nc_test/tst_utf8_validate.c and nc_test_utf8_phrases.c. If/when I can find a usable normalization test, I will incorporate that later.
2017-02-17 05:27:54 +08:00
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
/* Bison implementation for Yacc-like parsers in C
Resolves Github issue https://github.com/Unidata/netcdf-c/issues/349. Update utf8proc.[ch] to use the version now maintained by the Julia Language project (https://github.com/JuliaLang/utf8proc/blob/master/LICENSE.md). The license for the previous version was unacceptable for the Debian and Ubuntu release systems. The new version both updates the code and addresses the license issue. It turns out that the utf8proc software we are using was turned over to the Julia Language developers and the license terms changed to allow modification. (https://github.com/JuliaLang/utf8proc/blob/master/LICENSE.md). So the fix here is as follows: 1. Wrap the library with a fixed interface: libdispatch/dutf8.c and include/ncutf8.h. 2. Replace the existing utf8proc code with the new version from https://github.com/JuliaLang/utf8proc. 3. Add a couple more test cases: nc_test/tst_utf8_validate.c and nc_test_utf8_phrases.c. If/when I can find a usable normalization test, I will incorporate that later.
2017-02-17 05:27:54 +08:00
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
Copyright (C) 1984, 1989-1990, 2000-2015 Free Software Foundation, Inc.
Addressed an API-related usage of strncmp.
2015-11-25 07:19:36 +08:00
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
This program is free software: you can redistribute it and/or modify
moving to trunk subdir
2010-06-03 21:24:43 +08:00
it under the terms of the GNU General Public License as published by
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
Resolves Github issue https://github.com/Unidata/netcdf-c/issues/349. Update utf8proc.[ch] to use the version now maintained by the Julia Language project (https://github.com/JuliaLang/utf8proc/blob/master/LICENSE.md). The license for the previous version was unacceptable for the Debian and Ubuntu release systems. The new version both updates the code and addresses the license issue. It turns out that the utf8proc software we are using was turned over to the Julia Language developers and the license terms changed to allow modification. (https://github.com/JuliaLang/utf8proc/blob/master/LICENSE.md). So the fix here is as follows: 1. Wrap the library with a fixed interface: libdispatch/dutf8.c and include/ncutf8.h. 2. Replace the existing utf8proc code with the new version from https://github.com/JuliaLang/utf8proc. 3. Add a couple more test cases: nc_test/tst_utf8_validate.c and nc_test_utf8_phrases.c. If/when I can find a usable normalization test, I will incorporate that later.
2017-02-17 05:27:54 +08:00
moving to trunk subdir
2010-06-03 21:24:43 +08:00
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
Resolves Github issue https://github.com/Unidata/netcdf-c/issues/349. Update utf8proc.[ch] to use the version now maintained by the Julia Language project (https://github.com/JuliaLang/utf8proc/blob/master/LICENSE.md). The license for the previous version was unacceptable for the Debian and Ubuntu release systems. The new version both updates the code and addresses the license issue. It turns out that the utf8proc software we are using was turned over to the Julia Language developers and the license terms changed to allow modification. (https://github.com/JuliaLang/utf8proc/blob/master/LICENSE.md). So the fix here is as follows: 1. Wrap the library with a fixed interface: libdispatch/dutf8.c and include/ncutf8.h. 2. Replace the existing utf8proc code with the new version from https://github.com/JuliaLang/utf8proc. 3. Add a couple more test cases: nc_test/tst_utf8_validate.c and nc_test_utf8_phrases.c. If/when I can find a usable normalization test, I will incorporate that later.
2017-02-17 05:27:54 +08:00
moving to trunk subdir
2010-06-03 21:24:43 +08:00
You should have received a copy of the GNU General Public License
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
along with this program. If not, see <http://www.gnu.org/licenses/>. */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
/* As a special exception, you may create a larger work that contains
part or all of the Bison parser skeleton and distribute that work
under terms of your choice, so long as that work isn't itself a
parser generator using the skeleton or a modified version thereof
as a parser skeleton. Alternatively, if you modify or redistribute
the parser skeleton itself, you may (at your option) remove this
special exception, which will cause the skeleton and the resulting
Bison output files to be licensed under the GNU General Public
License without this special exception.
Resolves Github issue https://github.com/Unidata/netcdf-c/issues/349. Update utf8proc.[ch] to use the version now maintained by the Julia Language project (https://github.com/JuliaLang/utf8proc/blob/master/LICENSE.md). The license for the previous version was unacceptable for the Debian and Ubuntu release systems. The new version both updates the code and addresses the license issue. It turns out that the utf8proc software we are using was turned over to the Julia Language developers and the license terms changed to allow modification. (https://github.com/JuliaLang/utf8proc/blob/master/LICENSE.md). So the fix here is as follows: 1. Wrap the library with a fixed interface: libdispatch/dutf8.c and include/ncutf8.h. 2. Replace the existing utf8proc code with the new version from https://github.com/JuliaLang/utf8proc. 3. Add a couple more test cases: nc_test/tst_utf8_validate.c and nc_test_utf8_phrases.c. If/when I can find a usable normalization test, I will incorporate that later.
2017-02-17 05:27:54 +08:00
moving to trunk subdir
2010-06-03 21:24:43 +08:00
This special exception was added by the Free Software Foundation in
version 2.2 of Bison. */
/* C LALR(1) parser skeleton written by Richard Stallman, by
simplifying the original so-called "semantic" parser. */
/* All symbols defined below should begin with yy or YY, to avoid
infringing on user name space. This should be done even for local
variables, as they might otherwise be expanded by user macros.
There are some unavoidable exceptions within include files to
define necessary library symbols; they are noted "INFRINGES ON
USER NAME SPACE" below. */
/* Identify Bison output. */
#define YYBISON 1
/* Bison version. */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
#define YYBISON_VERSION "3.0.4"
moving to trunk subdir
2010-06-03 21:24:43 +08:00
/* Skeleton name. */
#define YYSKELETON_NAME "yacc.c"
/* Pure parsers. */
#define YYPURE 0
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
/* Push parsers. */
#define YYPUSH 0
Working out an error with unistd.h in windows.
2017-01-31 05:54:00 +08:00
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
/* Pull parsers. */
#define YYPULL 1
Working out an error with unistd.h in windows.
2017-01-31 05:54:00 +08:00
merge-squash
2015-08-16 06:26:35 +08:00
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
/* Substitute the variable and function names. */
#define yyparse ncgparse
#define yylex ncglex
#define yyerror ncgerror
#define yydebug ncgdebug
#define yynerrs ncgnerrs
Added a tweak to prevent problems with ncdump and hdf5 trying to correct for a lack of ssize_t.
2016-05-11 05:52:46 +08:00
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
#define yylval ncglval
#define yychar ncgchar
Corrected an issue on Linux, jumping back over to Windows to see if the issue persists.
2016-05-12 05:38:45 +08:00
/* Copy the first part of user declarations. */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
#line 11 "ncgen.y" /* yacc.c:339 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
/*
Changed calls in tests from deprecated _ubyte functions to equivalent _uchar functions.
2010-06-23 06:41:04 +08:00
static char SccsId[] = "$Id: ncgen.y,v 1.42 2010/05/18 21:32:46 dmh Exp $";
moving to trunk subdir
2010-06-03 21:24:43 +08:00
*/
#include "includes.h"
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#include "netcdf_aux.h"
Things are working?
2016-05-12 05:31:17 +08:00
#include "ncgeny.h"
#include "ncgen.h"
changed macro STREQ to NCSTREQ to avoid name collusion with HDF4 library
2018-05-12 22:55:51 +08:00
#ifdef USE_NETCDF4
Fix errors when building on big-endian machine re: issue https://github.com/Unidata/netcdf-c/issues/1278 re: issue https://github.com/Unidata/netcdf-c/issues/876 re: issue https://github.com/Unidata/netcdf-c/issues/806 * Major change to the handling of 8-byte parameters for nc_def_var_filter. The old code was not well thought out. * The new algorithm is documented in docs/filters.md. * Added new utility file plugins/H5Zutil.c to support * Modified plugins/H5Zmisc.c to use new algorithm the new algorithm. * Renamed include/ncfilter.h to include/netcdf_filter.h and made it an installed header so clients can access the new algorithm utility. * Fixed nc_test4/tst_filterparser.c and nc_test4/test_filter_misc.c to use the new algorithm * libdap4/ fixes: * d4swap.c has an error in the endian pre-processing such that record counts were not being swapped correctly. * d4data.c had an error in that checksums were being computed after endian swapping rather than before. * ocinitialize() was never being called, so xxdr bigendian handling was never set correctly. * Required adding debug statements to occompile * Found and fixed memory leak in ncdump.c Not tested: * HDF4 * Pnetcdf * parallel HDF5
2019-02-01 12:13:06 +08:00
#include "netcdf_filter.h"
changed macro STREQ to NCSTREQ to avoid name collusion with HDF4 library
2018-05-12 22:55:51 +08:00
#endif
fix NCF-120
2011-09-16 00:57:16 +08:00
2011-09-17 02:36:08 +08:00
/* Following are in ncdump (for now)*/
/* Need some (unused) definitions to get it to compile */
#define ncatt_t void*
#define ncvar_t void
1. synch changes with oc2.0 2. Fix a bug in ncgen to catch a special case of a malformed datalist.
2013-06-27 02:55:30 +08:00
#include "nctime.h"
moving to trunk subdir
2010-06-03 21:24:43 +08:00
/* parser controls */
#define YY_NO_INPUT 1
/* True if string a equals string b*/
changed macro STREQ to NCSTREQ to avoid name collusion with HDF4 library
2018-05-12 22:55:51 +08:00
#ifndef NCSTREQ
#define NCSTREQ(a, b) (*(a) == *(b) && strcmp((a), (b)) == 0)
Primary change: add dap4 support Specific changes: 1. Add dap4 code: libdap4 and dap4_test. Note that until the d4ts server problem is solved, dap4 is turned off. 2. Modify various files to support dap4 flags: configure.ac, Makefile.am, CMakeLists.txt, etc. 3. Add nc_test/test_common.sh. This centralizes the handling of the locations of various things in the build tree: e.g. where is ncgen.exe located. See nc_test/test_common.sh for details. 4. Modify .sh files to use test_common.sh 5. Obsolete separate oc2 by moving it to be part of netcdf-c. This means replacing code with netcdf-c equivalents. 5. Add --with-testserver to configure.ac to allow override of the servers to be used for --enable-dap-remote-tests. 6. There were multiple versions of nctypealignment code. Try to centralize in libdispatch/doffset.c and include/ncoffsets.h 7. Add a unit test for the ncuri code because of its complexity. 8. Move the findserver code out of libdispatch and into a separate, self contained program in ncdap_test and dap4_test. 9. Move the dispatch header files (nc{3,4}dispatch.h) to .../include because they are now shared by modules. 10. Revamp the handling of TOPSRCDIR and TOPBUILDDIR for shell scripts. 11. Make use of MREMAP if available 12. Misc. minor changes e.g. - #include <config.h> -> #include "config.h" - Add some no-install headers to /include - extern -> EXTERNL and vice versa as needed - misc header cleanup - clean up checking for misc. unix vs microsoft functions 13. Change copyright decls in some files to point to LICENSE file. 14. Add notes to RELEASENOTES.md
2017-03-09 08:01:10 +08:00
#endif
moving to trunk subdir
2010-06-03 21:24:43 +08:00
#define VLENSIZE (sizeof(nc_vlen_t))
#define MAXFLOATDIM 4294967295.0
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
/* mnemonics */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
typedef enum Attrkind {ATTRVAR, ATTRGLOBAL, DONTKNOW} Attrkind;
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#define ISCONST 1
#define ISLIST 0
moving to trunk subdir
2010-06-03 21:24:43 +08:00
typedef nc_vlen_t vlen_t;
/* We retain the old representation of the symbol list
as a linked list.
*/
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
List* symlist;
moving to trunk subdir
2010-06-03 21:24:43 +08:00
/* Track rootgroup separately*/
Symbol* rootgroup;
/* Track the group sequence */
static List* groupstack;
/* Provide a separate sequence for accumulating values
during the parse.
*/
static List* stack;
/* track homogeneity of types for data lists*/
static nc_type consttype;
/* Misc. */
static int stackbase;
static int stacklen;
static int count;
static int opaqueid; /* counter for opaque constants*/
static int arrayuid; /* counter for pseudo-array types*/
char* primtypenames[PRIMNO] = {
"nat",
"byte", "char", "short",
"int", "float", "double",
"ubyte", "ushort", "uint",
"int64", "uint64",
"string"
};
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
static int GLOBAL_SPECIAL = _NCPROPS_FLAG
| _ISNETCDF4_FLAG
| _SUPERBLOCK_FLAG
| _FORMAT_FLAG ;
Add provenance info for netcdf-4 files. This consists of a persistent attribute named _NCProperties plus two computed attributes _IsNetcdf4 and _SuperblockVersion. See the 'Provenance Attributes' section of docs/attribute_conventions.md for details.
2016-05-04 11:17:06 +08:00
moving to trunk subdir
2010-06-03 21:24:43 +08:00
/*Defined in ncgen.l*/
extern int lineno; /* line number for error messages */
Resolve Lynton's vlen problems (partially) re: jira NCF-145
2012-02-14 08:25:32 +08:00
extern Bytebuffer* lextext; /* name or string with escapes removed */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
extern double double_val; /* last double value read */
extern float float_val; /* last float value read */
extern long long int64_val; /* last int64 value read */
extern int int32_val; /* last int32 value read */
extern short int16_val; /* last short value read */
extern unsigned long long uint64_val; /* last int64 value read */
extern unsigned int uint32_val; /* last int32 value read */
extern unsigned short uint16_val; /* last short value read */
extern char char_val; /* last char value read */
extern signed char byte_val; /* last byte value read */
extern unsigned char ubyte_val; /* last byte value read */
/* Track definitions of dims, types, attributes, and vars*/
List* grpdefs;
List* dimdefs;
List* attdefs; /* variable-specific attributes*/
List* gattdefs; /* global attributes only*/
List* xattdefs; /* unknown attributes*/
List* typdefs;
List* vardefs;
List* condefs; /* non-dimension constants used in type defs*/
List* tmp;
/* Forward */
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
static NCConstant* makeconstdata(nc_type);
static NCConstant* evaluate(Symbol* fcn, Datalist* arglist);
static NCConstant* makeenumconstref(Symbol*);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
static void addtogroup(Symbol*);
static Symbol* currentgroup(void);
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
static Symbol* createrootgroup(const char*);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
static Symbol* creategroup(Symbol*);
static int dupobjectcheck(nc_class,Symbol*);
static void setpathcurrent(Symbol* sym);
static Symbol* makeattribute(Symbol*,Symbol*,Symbol*,Datalist*,Attrkind);
static Symbol* makeprimitivetype(nc_type i);
static Symbol* makespecial(int tag, Symbol* vsym, Symbol* tsym, void* data, int isconst);
static int containsfills(Datalist* list);
Fixed the following Jira minor bugs: NCF-42: _Format attribute sometimes being ignored NCF-43: Fixed unsigned long long parsing. NCF-47: Make opendap code properly handle illegal names like "x.y" by supressing them NCF-49: check for uint type NCF-50: properly handle username:pwd embedded in urls.
2011-05-13 01:51:32 +08:00
static void vercheck(int ncid);
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
static long long extractint(NCConstant* con);
This is the initial step in moving to the new higher performance (I hope) metadata mechanism. This mostly just adds new pieces of code (e.g. nclistmap) and does some minor fixes. It should be transparent to everything else. The next set of changes will be the big step.
2018-02-09 10:53:40 +08:00
#ifdef USE_NETCDF4
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
static int parsefilterflag(const char* sdata0, Specialdata* special);
This is the initial step in moving to the new higher performance (I hope) metadata mechanism. This mostly just adds new pieces of code (e.g. nclistmap) and does some minor fixes. It should be transparent to everything else. The next set of changes will be the big step.
2018-02-09 10:53:40 +08:00
#endif
moving to trunk subdir
2010-06-03 21:24:43 +08:00
int yylex(void);
#ifndef NO_STDARG
static void yyerror(const char *fmt, ...);
#else
static void yyerror(fmt,va_alist) const char* fmt; va_dcl;
#endif
/* Extern */
extern int lex_init(void);
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 210 "ncgeny.c" /* yacc.c:339 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
# ifndef YY_NULLPTR
# if defined __cplusplus && 201103L <= __cplusplus
# define YY_NULLPTR nullptr
# else
# define YY_NULLPTR 0
# endif
# endif
moving to trunk subdir
2010-06-03 21:24:43 +08:00
/* Enabling verbose error messages. */
#ifdef YYERROR_VERBOSE
# undef YYERROR_VERBOSE
# define YYERROR_VERBOSE 1
#else
Fixed NCF-104
2011-07-28 04:48:58 +08:00
# define YYERROR_VERBOSE 1
moving to trunk subdir
2010-06-03 21:24:43 +08:00
#endif
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
/* In a future release of Bison, this section will be replaced
by #include "ncgeny.h". */
#ifndef YY_NCG_NCGEN_TAB_H_INCLUDED
# define YY_NCG_NCGEN_TAB_H_INCLUDED
/* Debug traces. */
#ifndef YYDEBUG
# define YYDEBUG 1
#endif
#if YYDEBUG
extern int ncgdebug;
Add provenance info for netcdf-4 files. This consists of a persistent attribute named _NCProperties plus two computed attributes _IsNetcdf4 and _SuperblockVersion. See the 'Provenance Attributes' section of docs/attribute_conventions.md for details.
2016-05-04 11:17:06 +08:00
#endif
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
/* Token type. */
#ifndef YYTOKENTYPE
# define YYTOKENTYPE
enum yytokentype
{
NC_UNLIMITED_K = 258,
CHAR_K = 259,
BYTE_K = 260,
SHORT_K = 261,
INT_K = 262,
FLOAT_K = 263,
DOUBLE_K = 264,
UBYTE_K = 265,
USHORT_K = 266,
UINT_K = 267,
INT64_K = 268,
UINT64_K = 269,
STRING_K = 270,
IDENT = 271,
TERMSTRING = 272,
CHAR_CONST = 273,
BYTE_CONST = 274,
SHORT_CONST = 275,
INT_CONST = 276,
INT64_CONST = 277,
UBYTE_CONST = 278,
USHORT_CONST = 279,
UINT_CONST = 280,
UINT64_CONST = 281,
FLOAT_CONST = 282,
DOUBLE_CONST = 283,
DIMENSIONS = 284,
VARIABLES = 285,
NETCDF = 286,
DATA = 287,
TYPES = 288,
COMPOUND = 289,
ENUM = 290,
OPAQUE_ = 291,
OPAQUESTRING = 292,
GROUP = 293,
PATH = 294,
FILLMARKER = 295,
NIL = 296,
_FILLVALUE = 297,
_FORMAT = 298,
_STORAGE = 299,
_CHUNKSIZES = 300,
_DEFLATELEVEL = 301,
_SHUFFLE = 302,
_ENDIANNESS = 303,
_NOFILL = 304,
_FLETCHER32 = 305,
_NCPROPS = 306,
_ISNETCDF4 = 307,
_SUPERBLOCK = 308,
_FILTER = 309,
DATASETID = 310
};
#endif
/* Value type. */
Added a tweak to prevent problems with ncdump and hdf5 trying to correct for a lack of ssize_t.
2016-05-11 05:52:46 +08:00
#if ! defined YYSTYPE && ! defined YYSTYPE_IS_DECLARED
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
union YYSTYPE
Resolves Github issue https://github.com/Unidata/netcdf-c/issues/349. Update utf8proc.[ch] to use the version now maintained by the Julia Language project (https://github.com/JuliaLang/utf8proc/blob/master/LICENSE.md). The license for the previous version was unacceptable for the Debian and Ubuntu release systems. The new version both updates the code and addresses the license issue. It turns out that the utf8proc software we are using was turned over to the Julia Language developers and the license terms changed to allow modification. (https://github.com/JuliaLang/utf8proc/blob/master/LICENSE.md). So the fix here is as follows: 1. Wrap the library with a fixed interface: libdispatch/dutf8.c and include/ncutf8.h. 2. Replace the existing utf8proc code with the new version from https://github.com/JuliaLang/utf8proc. 3. Add a couple more test cases: nc_test/tst_utf8_validate.c and nc_test_utf8_phrases.c. If/when I can find a usable normalization test, I will incorporate that later.
2017-02-17 05:27:54 +08:00
{
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 149 "ncgen.y" /* yacc.c:355 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
moving to trunk subdir
2010-06-03 21:24:43 +08:00
Symbol* sym;
unsigned long size; /* allow for zero size to indicate e.g. UNLIMITED*/
long mark; /* track indices into the sequence*/
int nctype; /* for tracking attribute list type*/
Datalist* datalist;
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
NCConstant* constant;
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 315 "ncgeny.c" /* yacc.c:355 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
};
typedef union YYSTYPE YYSTYPE;
Merge branch 'master' into filters.dmh
2017-11-14 02:15:02 +08:00
# define YYSTYPE_IS_TRIVIAL 1
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
# define YYSTYPE_IS_DECLARED 1
moving to trunk subdir
2010-06-03 21:24:43 +08:00
#endif
[NCF-271] Fix bug introduced by [NCF-267]. The bug was that octal constants that had the highest bit set (e.g. '\200') were not recognized as proper octal constants. Fix was to keep as integer until it was needed as an 8-bit byte.
2013-09-27 00:10:26 +08:00
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
extern YYSTYPE ncglval;
Added a tweak to prevent problems with ncdump and hdf5 trying to correct for a lack of ssize_t.
2016-05-11 05:52:46 +08:00
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
int ncgparse (void);
Merging master into branch.
2017-02-28 02:00:24 +08:00
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
#endif /* !YY_NCG_NCGEN_TAB_H_INCLUDED */
Merge branch 'master' into filters.dmh
2017-11-14 02:15:02 +08:00
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
/* Copy the second part of user declarations. */
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 332 "ncgeny.c" /* yacc.c:358 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
#ifdef short
# undef short
#endif
#ifdef YYTYPE_UINT8
typedef YYTYPE_UINT8 yytype_uint8;
#else
typedef unsigned char yytype_uint8;
#endif
#ifdef YYTYPE_INT8
typedef YYTYPE_INT8 yytype_int8;
Merge branch 'master' into filters.dmh
2017-11-14 02:15:02 +08:00
#else
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
typedef signed char yytype_int8;
moving to trunk subdir
2010-06-03 21:24:43 +08:00
#endif
#ifdef YYTYPE_UINT16
typedef YYTYPE_UINT16 yytype_uint16;
#else
typedef unsigned short int yytype_uint16;
#endif
#ifdef YYTYPE_INT16
typedef YYTYPE_INT16 yytype_int16;
#else
typedef short int yytype_int16;
#endif
#ifndef YYSIZE_T
# ifdef __SIZE_TYPE__
# define YYSIZE_T __SIZE_TYPE__
# elif defined size_t
# define YYSIZE_T size_t
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
# elif ! defined YYSIZE_T
moving to trunk subdir
2010-06-03 21:24:43 +08:00
# include <stddef.h> /* INFRINGES ON USER NAME SPACE */
# define YYSIZE_T size_t
# else
# define YYSIZE_T unsigned int
# endif
#endif
#define YYSIZE_MAXIMUM ((YYSIZE_T) -1)
#ifndef YY_
disallow uppercase section keywords
2010-08-26 03:01:07 +08:00
# if defined YYENABLE_NLS && YYENABLE_NLS
moving to trunk subdir
2010-06-03 21:24:43 +08:00
# if ENABLE_NLS
# include <libintl.h> /* INFRINGES ON USER NAME SPACE */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
# define YY_(Msgid) dgettext ("bison-runtime", Msgid)
moving to trunk subdir
2010-06-03 21:24:43 +08:00
# endif
# endif
# ifndef YY_
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
# define YY_(Msgid) Msgid
# endif
#endif
#ifndef YY_ATTRIBUTE
# if (defined __GNUC__ \
&& (2 < __GNUC__ || (__GNUC__ == 2 && 96 <= __GNUC_MINOR__))) \
|| defined __SUNPRO_C && 0x5110 <= __SUNPRO_C
# define YY_ATTRIBUTE(Spec) __attribute__(Spec)
# else
# define YY_ATTRIBUTE(Spec) /* empty */
# endif
#endif
#ifndef YY_ATTRIBUTE_PURE
# define YY_ATTRIBUTE_PURE YY_ATTRIBUTE ((__pure__))
#endif
#ifndef YY_ATTRIBUTE_UNUSED
# define YY_ATTRIBUTE_UNUSED YY_ATTRIBUTE ((__unused__))
#endif
#if !defined _Noreturn \
&& (!defined __STDC_VERSION__ || __STDC_VERSION__ < 201112)
# if defined _MSC_VER && 1200 <= _MSC_VER
# define _Noreturn __declspec (noreturn)
# else
# define _Noreturn YY_ATTRIBUTE ((__noreturn__))
[NCF-271] Fix bug introduced by [NCF-267]. The bug was that octal constants that had the highest bit set (e.g. '\200') were not recognized as proper octal constants. Fix was to keep as integer until it was needed as an 8-bit byte.
2013-09-27 00:10:26 +08:00
# endif
#endif
moving to trunk subdir
2010-06-03 21:24:43 +08:00
/* Suppress unused-variable warnings by "using" E. */
#if ! defined lint || defined __GNUC__
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
# define YYUSE(E) ((void) (E))
moving to trunk subdir
2010-06-03 21:24:43 +08:00
#else
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
# define YYUSE(E) /* empty */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
#endif
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
#if defined __GNUC__ && 407 <= __GNUC__ * 100 + __GNUC_MINOR__
/* Suppress an incorrect diagnostic about yylval being uninitialized. */
# define YY_IGNORE_MAYBE_UNINITIALIZED_BEGIN \
_Pragma ("GCC diagnostic push") \
_Pragma ("GCC diagnostic ignored \"-Wuninitialized\"")\
_Pragma ("GCC diagnostic ignored \"-Wmaybe-uninitialized\"")
# define YY_IGNORE_MAYBE_UNINITIALIZED_END \
_Pragma ("GCC diagnostic pop")
Merging master into branch.
2017-02-28 02:00:24 +08:00
#else
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
# define YY_INITIAL_VALUE(Value) Value
Primary change: add dap4 support Specific changes: 1. Add dap4 code: libdap4 and dap4_test. Note that until the d4ts server problem is solved, dap4 is turned off. 2. Modify various files to support dap4 flags: configure.ac, Makefile.am, CMakeLists.txt, etc. 3. Add nc_test/test_common.sh. This centralizes the handling of the locations of various things in the build tree: e.g. where is ncgen.exe located. See nc_test/test_common.sh for details. 4. Modify .sh files to use test_common.sh 5. Obsolete separate oc2 by moving it to be part of netcdf-c. This means replacing code with netcdf-c equivalents. 5. Add --with-testserver to configure.ac to allow override of the servers to be used for --enable-dap-remote-tests. 6. There were multiple versions of nctypealignment code. Try to centralize in libdispatch/doffset.c and include/ncoffsets.h 7. Add a unit test for the ncuri code because of its complexity. 8. Move the findserver code out of libdispatch and into a separate, self contained program in ncdap_test and dap4_test. 9. Move the dispatch header files (nc{3,4}dispatch.h) to .../include because they are now shared by modules. 10. Revamp the handling of TOPSRCDIR and TOPBUILDDIR for shell scripts. 11. Make use of MREMAP if available 12. Misc. minor changes e.g. - #include <config.h> -> #include "config.h" - Add some no-install headers to /include - extern -> EXTERNL and vice versa as needed - misc header cleanup - clean up checking for misc. unix vs microsoft functions 13. Change copyright decls in some files to point to LICENSE file. 14. Add notes to RELEASENOTES.md
2017-03-09 08:01:10 +08:00
#endif
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
#ifndef YY_IGNORE_MAYBE_UNINITIALIZED_BEGIN
# define YY_IGNORE_MAYBE_UNINITIALIZED_BEGIN
# define YY_IGNORE_MAYBE_UNINITIALIZED_END
Add provenance info for netcdf-4 files. This consists of a persistent attribute named _NCProperties plus two computed attributes _IsNetcdf4 and _SuperblockVersion. See the 'Provenance Attributes' section of docs/attribute_conventions.md for details.
2016-05-04 11:17:06 +08:00
#endif
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
#ifndef YY_INITIAL_VALUE
# define YY_INITIAL_VALUE(Value) /* Nothing. */
#endif
Add provenance info for netcdf-4 files. This consists of a persistent attribute named _NCProperties plus two computed attributes _IsNetcdf4 and _SuperblockVersion. See the 'Provenance Attributes' section of docs/attribute_conventions.md for details.
2016-05-04 11:17:06 +08:00
moving to trunk subdir
2010-06-03 21:24:43 +08:00
#if ! defined yyoverflow || YYERROR_VERBOSE
/* The parser invokes alloca or malloc; define the necessary symbols. */
# ifdef YYSTACK_USE_ALLOCA
# if YYSTACK_USE_ALLOCA
# ifdef __GNUC__
# define YYSTACK_ALLOC __builtin_alloca
# elif defined __BUILTIN_VA_ARG_INCR
# include <alloca.h> /* INFRINGES ON USER NAME SPACE */
# elif defined _AIX
# define YYSTACK_ALLOC __alloca
# elif defined _MSC_VER
# include <malloc.h> /* INFRINGES ON USER NAME SPACE */
# define alloca _alloca
# else
# define YYSTACK_ALLOC alloca
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
# if ! defined _ALLOCA_H && ! defined EXIT_SUCCESS
moving to trunk subdir
2010-06-03 21:24:43 +08:00
# include <stdlib.h> /* INFRINGES ON USER NAME SPACE */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
/* Use EXIT_SUCCESS as a witness for stdlib.h. */
# ifndef EXIT_SUCCESS
# define EXIT_SUCCESS 0
moving to trunk subdir
2010-06-03 21:24:43 +08:00
# endif
# endif
# endif
# endif
# endif
# ifdef YYSTACK_ALLOC
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
/* Pacify GCC's 'empty if-body' warning. */
# define YYSTACK_FREE(Ptr) do { /* empty */; } while (0)
moving to trunk subdir
2010-06-03 21:24:43 +08:00
# ifndef YYSTACK_ALLOC_MAXIMUM
/* The OS might guarantee only one guard page at the bottom of the stack,
and a page size can be as small as 4096 bytes. So we cannot safely
invoke alloca (N) if N exceeds 4096. Use a slightly smaller number
to allow for a few compiler-allocated temporary stack slots. */
# define YYSTACK_ALLOC_MAXIMUM 4032 /* reasonable circa 2006 */
# endif
# else
# define YYSTACK_ALLOC YYMALLOC
# define YYSTACK_FREE YYFREE
# ifndef YYSTACK_ALLOC_MAXIMUM
# define YYSTACK_ALLOC_MAXIMUM YYSIZE_MAXIMUM
# endif
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
# if (defined __cplusplus && ! defined EXIT_SUCCESS \
moving to trunk subdir
2010-06-03 21:24:43 +08:00
&& ! ((defined YYMALLOC || defined malloc) \
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
&& (defined YYFREE || defined free)))
moving to trunk subdir
2010-06-03 21:24:43 +08:00
# include <stdlib.h> /* INFRINGES ON USER NAME SPACE */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
# ifndef EXIT_SUCCESS
# define EXIT_SUCCESS 0
moving to trunk subdir
2010-06-03 21:24:43 +08:00
# endif
# endif
# ifndef YYMALLOC
# define YYMALLOC malloc
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
# if ! defined malloc && ! defined EXIT_SUCCESS
moving to trunk subdir
2010-06-03 21:24:43 +08:00
void *malloc (YYSIZE_T); /* INFRINGES ON USER NAME SPACE */
# endif
# endif
# ifndef YYFREE
# define YYFREE free
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
# if ! defined free && ! defined EXIT_SUCCESS
moving to trunk subdir
2010-06-03 21:24:43 +08:00
void free (void *); /* INFRINGES ON USER NAME SPACE */
# endif
# endif
# endif
#endif /* ! defined yyoverflow || YYERROR_VERBOSE */
#if (! defined yyoverflow \
&& (! defined __cplusplus \
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
|| (defined YYSTYPE_IS_TRIVIAL && YYSTYPE_IS_TRIVIAL)))
moving to trunk subdir
2010-06-03 21:24:43 +08:00
/* A type that is properly aligned for any stack member. */
union yyalloc
{
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
yytype_int16 yyss_alloc;
YYSTYPE yyvs_alloc;
};
moving to trunk subdir
2010-06-03 21:24:43 +08:00
/* The size of the maximum gap between one aligned stack and the next. */
# define YYSTACK_GAP_MAXIMUM (sizeof (union yyalloc) - 1)
/* The size of an array large to enough to hold all stacks, each with
N elements. */
# define YYSTACK_BYTES(N) \
((N) * (sizeof (yytype_int16) + sizeof (YYSTYPE)) \
+ YYSTACK_GAP_MAXIMUM)
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
# define YYCOPY_NEEDED 1
Addressed an API-related usage of strncmp.
2015-11-25 07:19:36 +08:00
/* Relocate STACK from its old location to the new one. The
local variables YYSIZE and YYSTACKSIZE give the old and new number of
elements in the stack, and YYPTR gives the new location of the
stack. Advance YYPTR to a properly aligned location for the next
stack. */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
# define YYSTACK_RELOCATE(Stack_alloc, Stack) \
do \
{ \
YYSIZE_T yynewbytes; \
YYCOPY (&yyptr->Stack_alloc, Stack, yysize); \
Stack = &yyptr->Stack_alloc; \
yynewbytes = yystacksize * sizeof (*Stack) + YYSTACK_GAP_MAXIMUM; \
yyptr += yynewbytes / sizeof (*yyptr); \
} \
while (0)
Addressed an API-related usage of strncmp.
2015-11-25 07:19:36 +08:00
#endif
1) fix out of date ncgentab/ncgenyy files 2)fix Jira-ncf213 bug and add test case
2013-01-04 04:45:34 +08:00
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
#if defined YYCOPY_NEEDED && YYCOPY_NEEDED
/* Copy COUNT objects from SRC to DST. The source and destination do
not overlap. */
# ifndef YYCOPY
# if defined __GNUC__ && 1 < __GNUC__
# define YYCOPY(Dst, Src, Count) \
__builtin_memcpy (Dst, Src, (Count) * sizeof (*(Src)))
# else
# define YYCOPY(Dst, Src, Count) \
do \
{ \
YYSIZE_T yyi; \
for (yyi = 0; yyi < (Count); yyi++) \
(Dst)[yyi] = (Src)[yyi]; \
} \
while (0)
# endif
# endif
#endif /* !YYCOPY_NEEDED */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
/* YYFINAL -- State number of the termination state. */
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
#define YYFINAL 5
moving to trunk subdir
2010-06-03 21:24:43 +08:00
/* YYLAST -- Last index in YYTABLE. */
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
#define YYLAST 393
moving to trunk subdir
2010-06-03 21:24:43 +08:00
/* YYNTOKENS -- Number of terminals. */
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
#define YYNTOKENS 65
moving to trunk subdir
2010-06-03 21:24:43 +08:00
/* YYNNTS -- Number of nonterminals. */
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
#define YYNNTS 67
moving to trunk subdir
2010-06-03 21:24:43 +08:00
/* YYNRULES -- Number of rules. */
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
#define YYNRULES 153
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
/* YYNSTATES -- Number of states. */
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
#define YYNSTATES 262
moving to trunk subdir
2010-06-03 21:24:43 +08:00
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
/* YYTRANSLATE[YYX] -- Symbol number corresponding to YYX as returned
by yylex, with out-of-bounds checking. */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
#define YYUNDEFTOK 2
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
#define YYMAXUTOK 310
moving to trunk subdir
2010-06-03 21:24:43 +08:00
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
#define YYTRANSLATE(YYX) \
moving to trunk subdir
2010-06-03 21:24:43 +08:00
((unsigned int) (YYX) <= YYMAXUTOK ? yytranslate[YYX] : YYUNDEFTOK)
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
/* YYTRANSLATE[TOKEN-NUM] -- Symbol number corresponding to TOKEN-NUM
as returned by yylex, without out-of-bounds checking. */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
static const yytype_uint8 yytranslate[] =
{
0, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
61, 62, 63, 2, 59, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 64, 58,
2, 60, 2, 2, 2, 2, 2, 2, 2, 2,
moving to trunk subdir
2010-06-03 21:24:43 +08:00
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
2, 2, 2, 56, 2, 57, 2, 2, 2, 2,
moving to trunk subdir
2010-06-03 21:24:43 +08:00
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 1, 2, 3, 4,
5, 6, 7, 8, 9, 10, 11, 12, 13, 14,
15, 16, 17, 18, 19, 20, 21, 22, 23, 24,
25, 26, 27, 28, 29, 30, 31, 32, 33, 34,
35, 36, 37, 38, 39, 40, 41, 42, 43, 44,
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
45, 46, 47, 48, 49, 50, 51, 52, 53, 54,
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
55
moving to trunk subdir
2010-06-03 21:24:43 +08:00
};
#if YYDEBUG
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
/* YYRLINE[YYN] -- Source line where rule number YYN was defined. */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
static const yytype_uint16 yyrline[] =
{
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
0, 231, 231, 237, 239, 246, 253, 253, 256, 265,
255, 270, 271, 272, 276, 276, 278, 288, 288, 291,
292, 293, 294, 297, 297, 300, 330, 332, 349, 358,
370, 384, 417, 418, 421, 435, 436, 437, 438, 439,
440, 441, 442, 443, 444, 445, 446, 449, 450, 451,
454, 455, 458, 458, 460, 461, 465, 473, 483, 495,
496, 497, 500, 501, 504, 504, 506, 531, 535, 539,
568, 569, 572, 573, 577, 591, 595, 600, 629, 630,
634, 635, 640, 650, 670, 681, 692, 711, 718, 718,
721, 723, 725, 727, 729, 738, 749, 751, 753, 755,
757, 759, 761, 763, 765, 767, 769, 774, 781, 790,
791, 792, 795, 796, 799, 803, 804, 808, 812, 813,
818, 819, 823, 824, 825, 826, 827, 828, 832, 836,
840, 842, 847, 848, 849, 850, 851, 852, 853, 854,
855, 856, 857, 858, 862, 863, 867, 869, 871, 873,
878, 882, 883, 889
moving to trunk subdir
2010-06-03 21:24:43 +08:00
};
#endif
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
#if YYDEBUG || YYERROR_VERBOSE || 1
moving to trunk subdir
2010-06-03 21:24:43 +08:00
/* YYTNAME[SYMBOL-NUM] -- String name of the symbol SYMBOL-NUM.
First, the terminals, then, starting at YYNTOKENS, nonterminals. */
static const char *const yytname[] =
{
"$end", "error", "$undefined", "NC_UNLIMITED_K", "CHAR_K", "BYTE_K",
"SHORT_K", "INT_K", "FLOAT_K", "DOUBLE_K", "UBYTE_K", "USHORT_K",
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
"UINT_K", "INT64_K", "UINT64_K", "STRING_K", "IDENT", "TERMSTRING",
"CHAR_CONST", "BYTE_CONST", "SHORT_CONST", "INT_CONST", "INT64_CONST",
"UBYTE_CONST", "USHORT_CONST", "UINT_CONST", "UINT64_CONST",
"FLOAT_CONST", "DOUBLE_CONST", "DIMENSIONS", "VARIABLES", "NETCDF",
"DATA", "TYPES", "COMPOUND", "ENUM", "OPAQUE_", "OPAQUESTRING", "GROUP",
"PATH", "FILLMARKER", "NIL", "_FILLVALUE", "_FORMAT", "_STORAGE",
"_CHUNKSIZES", "_DEFLATELEVEL", "_SHUFFLE", "_ENDIANNESS", "_NOFILL",
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
"_FLETCHER32", "_NCPROPS", "_ISNETCDF4", "_SUPERBLOCK", "_FILTER",
"DATASETID", "'{'", "'}'", "';'", "','", "'='", "'('", "')'", "'*'",
"':'", "$accept", "ncdesc", "datasetid", "rootgroup", "groupbody",
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
"subgrouplist", "namedgroup", "$@1", "$@2", "typesection", "typedecls",
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
"typename", "type_or_attr_decl", "typedecl", "optsemicolon", "enumdecl",
"enumidlist", "enumid", "opaquedecl", "vlendecl", "compounddecl",
"fields", "field", "primtype", "dimsection", "dimdecls",
Primary change: add dap4 support Specific changes: 1. Add dap4 code: libdap4 and dap4_test. Note that until the d4ts server problem is solved, dap4 is turned off. 2. Modify various files to support dap4 flags: configure.ac, Makefile.am, CMakeLists.txt, etc. 3. Add nc_test/test_common.sh. This centralizes the handling of the locations of various things in the build tree: e.g. where is ncgen.exe located. See nc_test/test_common.sh for details. 4. Modify .sh files to use test_common.sh 5. Obsolete separate oc2 by moving it to be part of netcdf-c. This means replacing code with netcdf-c equivalents. 5. Add --with-testserver to configure.ac to allow override of the servers to be used for --enable-dap-remote-tests. 6. There were multiple versions of nctypealignment code. Try to centralize in libdispatch/doffset.c and include/ncoffsets.h 7. Add a unit test for the ncuri code because of its complexity. 8. Move the findserver code out of libdispatch and into a separate, self contained program in ncdap_test and dap4_test. 9. Move the dispatch header files (nc{3,4}dispatch.h) to .../include because they are now shared by modules. 10. Revamp the handling of TOPSRCDIR and TOPBUILDDIR for shell scripts. 11. Make use of MREMAP if available 12. Misc. minor changes e.g. - #include <config.h> -> #include "config.h" - Add some no-install headers to /include - extern -> EXTERNL and vice versa as needed - misc header cleanup - clean up checking for misc. unix vs microsoft functions 13. Change copyright decls in some files to point to LICENSE file. 14. Add notes to RELEASENOTES.md
2017-03-09 08:01:10 +08:00
"dim_or_attr_decl", "dimdeclist", "dimdecl", "dimd", "vasection",
"vadecls", "vadecl_or_attr", "vardecl", "varlist", "varspec", "dimspec",
"dimlist", "dimref", "fieldlist", "fieldspec", "fielddimspec",
"fielddimlist", "fielddim", "varref", "typeref", "type_var_ref",
"attrdecllist", "attrdecl", "path", "datasection", "datadecls",
"datadecl", "datalist", "datalist0", "datalist1", "dataitem",
"constdata", "econstref", "function", "arglist", "simpleconstant",
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
"intlist", "constint", "conststring", "constbool", "ident", YY_NULLPTR
moving to trunk subdir
2010-06-03 21:24:43 +08:00
};
#endif
# ifdef YYPRINT
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
/* YYTOKNUM[NUM] -- (External) token number corresponding to the
(internal) symbol number NUM (which must be that of a token). */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
static const yytype_uint16 yytoknum[] =
{
0, 256, 257, 258, 259, 260, 261, 262, 263, 264,
265, 266, 267, 268, 269, 270, 271, 272, 273, 274,
275, 276, 277, 278, 279, 280, 281, 282, 283, 284,
285, 286, 287, 288, 289, 290, 291, 292, 293, 294,
295, 296, 297, 298, 299, 300, 301, 302, 303, 304,
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
305, 306, 307, 308, 309, 310, 123, 125, 59, 44,
61, 40, 41, 42, 58
moving to trunk subdir
2010-06-03 21:24:43 +08:00
};
# endif
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
#define YYPACT_NINF -145
Resolves Github issue https://github.com/Unidata/netcdf-c/issues/349. Update utf8proc.[ch] to use the version now maintained by the Julia Language project (https://github.com/JuliaLang/utf8proc/blob/master/LICENSE.md). The license for the previous version was unacceptable for the Debian and Ubuntu release systems. The new version both updates the code and addresses the license issue. It turns out that the utf8proc software we are using was turned over to the Julia Language developers and the license terms changed to allow modification. (https://github.com/JuliaLang/utf8proc/blob/master/LICENSE.md). So the fix here is as follows: 1. Wrap the library with a fixed interface: libdispatch/dutf8.c and include/ncutf8.h. 2. Replace the existing utf8proc code with the new version from https://github.com/JuliaLang/utf8proc. 3. Add a couple more test cases: nc_test/tst_utf8_validate.c and nc_test_utf8_phrases.c. If/when I can find a usable normalization test, I will incorporate that later.
2017-02-17 05:27:54 +08:00
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
#define yypact_value_is_default(Yystate) \
(!!((Yystate) == (-145)))
Merging master into branch.
2017-02-28 02:00:24 +08:00
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
#define YYTABLE_NINF -108
Primary change: add dap4 support Specific changes: 1. Add dap4 code: libdap4 and dap4_test. Note that until the d4ts server problem is solved, dap4 is turned off. 2. Modify various files to support dap4 flags: configure.ac, Makefile.am, CMakeLists.txt, etc. 3. Add nc_test/test_common.sh. This centralizes the handling of the locations of various things in the build tree: e.g. where is ncgen.exe located. See nc_test/test_common.sh for details. 4. Modify .sh files to use test_common.sh 5. Obsolete separate oc2 by moving it to be part of netcdf-c. This means replacing code with netcdf-c equivalents. 5. Add --with-testserver to configure.ac to allow override of the servers to be used for --enable-dap-remote-tests. 6. There were multiple versions of nctypealignment code. Try to centralize in libdispatch/doffset.c and include/ncoffsets.h 7. Add a unit test for the ncuri code because of its complexity. 8. Move the findserver code out of libdispatch and into a separate, self contained program in ncdap_test and dap4_test. 9. Move the dispatch header files (nc{3,4}dispatch.h) to .../include because they are now shared by modules. 10. Revamp the handling of TOPSRCDIR and TOPBUILDDIR for shell scripts. 11. Make use of MREMAP if available 12. Misc. minor changes e.g. - #include <config.h> -> #include "config.h" - Add some no-install headers to /include - extern -> EXTERNL and vice versa as needed - misc header cleanup - clean up checking for misc. unix vs microsoft functions 13. Change copyright decls in some files to point to LICENSE file. 14. Add notes to RELEASENOTES.md
2017-03-09 08:01:10 +08:00
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
#define yytable_value_is_error(Yytable_value) \
0
Primary change: add dap4 support Specific changes: 1. Add dap4 code: libdap4 and dap4_test. Note that until the d4ts server problem is solved, dap4 is turned off. 2. Modify various files to support dap4 flags: configure.ac, Makefile.am, CMakeLists.txt, etc. 3. Add nc_test/test_common.sh. This centralizes the handling of the locations of various things in the build tree: e.g. where is ncgen.exe located. See nc_test/test_common.sh for details. 4. Modify .sh files to use test_common.sh 5. Obsolete separate oc2 by moving it to be part of netcdf-c. This means replacing code with netcdf-c equivalents. 5. Add --with-testserver to configure.ac to allow override of the servers to be used for --enable-dap-remote-tests. 6. There were multiple versions of nctypealignment code. Try to centralize in libdispatch/doffset.c and include/ncoffsets.h 7. Add a unit test for the ncuri code because of its complexity. 8. Move the findserver code out of libdispatch and into a separate, self contained program in ncdap_test and dap4_test. 9. Move the dispatch header files (nc{3,4}dispatch.h) to .../include because they are now shared by modules. 10. Revamp the handling of TOPSRCDIR and TOPBUILDDIR for shell scripts. 11. Make use of MREMAP if available 12. Misc. minor changes e.g. - #include <config.h> -> #include "config.h" - Add some no-install headers to /include - extern -> EXTERNL and vice versa as needed - misc header cleanup - clean up checking for misc. unix vs microsoft functions 13. Change copyright decls in some files to point to LICENSE file. 14. Add notes to RELEASENOTES.md
2017-03-09 08:01:10 +08:00
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
/* YYPACT[STATE-NUM] -- Index in YYTABLE of the portion describing
STATE-NUM. */
Merge branch 'master' into filters.dmh
2017-11-14 02:15:02 +08:00
static const yytype_int16 yypact[] =
Corrected a couple issues uncovered when revisiting https://github.com/Unidata/netcdf-c/issues/244
2017-06-15 04:01:09 +08:00
{
Merge branch 'master' into filters.dmh
2017-11-14 02:15:02 +08:00
-10, -19, 54, -145, 12, -145, 219, -145, -145, -145,
-145, -145, -145, -145, -145, -145, -145, -145, -145, -145,
-145, -145, -8, -145, -145, 354, -9, 26, 11, -145,
-145, 15, 28, 31, 32, 36, -11, 34, 130, 183,
70, 219, 83, 83, 45, 52, 301, 85, -145, -145,
-1, 42, 46, 49, 50, 51, 57, 58, 59, 60,
61, 85, 53, 183, -145, -145, 64, 64, 64, 64,
88, 255, 66, 219, 95, -145, -145, -145, -145, -145,
-145, -145, -145, -145, -145, -145, -145, -145, -145, -145,
-145, -145, -145, -145, -145, -145, -145, -145, -145, -145,
-145, -145, 301, -145, 68, -145, -145, -145, -145, -145,
-145, -145, 71, 75, 73, 77, 301, 83, 52, 52,
45, 83, 45, 45, 83, 301, 79, -145, 117, -145,
-145, -145, -145, -145, -145, 85, 78, -145, 219, 82,
86, -145, 84, -145, 87, 219, 118, 30, 301, 355,
-145, 301, 301, 68, -145, 90, -145, -145, -145, -145,
-145, -145, -145, 68, 354, 93, 96, 97, 100, -145,
85, 35, 219, 102, -145, 354, -145, 354, -145, -145,
-145, -28, -145, 219, 68, 68, 52, 291, 103, 85,
-145, 85, 85, 85, -145, -145, -145, -145, -145, 104,
-145, 105, -145, -32, 108, -145, 354, 107, 355, -145,
-145, -145, -145, 115, -145, 123, -145, 125, -145, 38,
-145, 140, -145, -145, 85, 3, -145, 301, 143, -145,
-145, 166, -145, 85, -7, -145, -145, 85, 52, -145,
145, 17, -145, -145, 68, -145, 106, -145, -145, -145,
23, -145, -145, -145, 3, -145, 219, -7, -145, -145,
-145, -145
Corrected a couple issues uncovered when revisiting https://github.com/Unidata/netcdf-c/issues/244
2017-06-15 04:01:09 +08:00
};
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
/* YYDEFACT[STATE-NUM] -- Default reduction number in state STATE-NUM.
Performed when YYTABLE does not specify something else to do. Zero
means the default is an error. */
static const yytype_uint8 yydefact[] =
{
0, 0, 0, 3, 0, 1, 88, 2, 35, 36,
37, 38, 39, 40, 41, 42, 43, 44, 45, 46,
153, 108, 0, 6, 87, 0, 85, 11, 0, 86,
107, 0, 0, 0, 0, 0, 0, 0, 0, 12,
47, 88, 0, 0, 0, 0, 117, 0, 4, 7,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 13, 14, 17, 23, 23, 23, 23,
87, 0, 0, 48, 59, 89, 150, 106, 90, 146,
148, 147, 149, 152, 151, 91, 92, 143, 132, 133,
134, 135, 136, 137, 138, 139, 140, 141, 142, 123,
124, 125, 117, 128, 93, 115, 116, 118, 120, 126,
127, 122, 107, 0, 0, 0, 117, 0, 0, 0,
0, 0, 0, 0, 0, 117, 0, 16, 0, 15,
24, 19, 22, 21, 20, 0, 0, 18, 49, 0,
52, 54, 0, 53, 107, 60, 109, 0, 0, 0,
8, 117, 117, 96, 98, 99, 144, 101, 102, 103,
105, 100, 104, 95, 0, 0, 0, 0, 0, 50,
0, 0, 61, 0, 64, 0, 65, 110, 5, 121,
119, 0, 130, 88, 97, 94, 0, 0, 0, 0,
85, 0, 0, 0, 51, 55, 58, 57, 56, 0,
62, 66, 67, 70, 0, 84, 111, 0, 0, 129,
6, 145, 31, 0, 32, 34, 75, 78, 29, 0,
26, 0, 30, 63, 0, 0, 69, 117, 0, 112,
131, 9, 33, 0, 0, 77, 25, 0, 0, 68,
70, 0, 72, 74, 114, 113, 0, 76, 83, 82,
0, 80, 27, 28, 0, 71, 88, 0, 79, 73,
10, 81
};
/* YYPGOTO[NTERM-NUM]. */
Merge branch 'master' into filters.dmh
2017-11-14 02:15:02 +08:00
static const yytype_int16 yypgoto[] =
moving to trunk subdir
2010-06-03 21:24:43 +08:00
{
Merge branch 'master' into filters.dmh
2017-11-14 02:15:02 +08:00
-145, -145, -145, -145, 24, -2, -145, -145, -145, -145,
-145, -128, 146, -145, -20, -145, -145, -25, -145, -145,
-145, -145, 27, -26, -145, -145, 80, -145, 43, -145,
-145, -145, 48, -145, -145, -3, -145, -145, -18, -145,
4, -145, -145, -17, -145, -30, -21, -40, -33, -44,
-145, -145, 33, -99, -145, -145, 94, -145, -145, -145,
-145, -144, -145, -35, -31, -100, -22
moving to trunk subdir
2010-06-03 21:24:43 +08:00
};
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
/* YYDEFGOTO[NTERM-NUM]. */
static const yytype_int16 yydefgoto[] =
{
-1, 2, 4, 7, 23, 36, 49, 183, 246, 40,
63, 126, 64, 65, 131, 66, 219, 220, 67, 68,
69, 187, 188, 24, 74, 138, 139, 140, 141, 142,
146, 172, 173, 174, 201, 202, 226, 241, 242, 215,
216, 235, 250, 251, 204, 25, 26, 27, 28, 29,
178, 206, 207, 104, 105, 106, 107, 108, 109, 110,
181, 111, 155, 83, 84, 85, 30
};
/* YYTABLE[YYPACT[STATE-NUM]] -- What to do in state STATE-NUM. If
positive, shift that token. If negative, reduce the rule whose
number is the opposite. If YYTABLE_NINF, syntax error. */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
static const yytype_int16 yytable[] =
{
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
35, 75, 103, 147, 37, 182, 72, 166, 20, 71,
86, 77, 78, 70, 248, 20, 60, 153, 249, 20,
158, 1, 160, 161, 112, 113, 163, 47, 115, 225,
72, 208, -107, 71, 209, 31, 3, 70, 197, 127,
143, 114, 21, 32, 33, 34, 48, 132, 133, 134,
37, 144, 184, 185, 5, 38, 79, 80, 103, 39,
81, 82, 76, 218, 230, 222, 79, 80, 6, 41,
81, 82, 103, 79, 80, 42, 254, 81, 82, 255,
112, 103, 257, 156, 157, 258, 154, 179, 43, 148,
159, 44, 45, 162, 112, 236, 46, 237, 50, 73,
76, 20, 116, 112, 103, 143, 117, 103, 103, 118,
119, 120, 176, 127, 128, 175, 144, 121, 122, 123,
124, 125, 130, 135, 137, 145, 112, 148, 244, 112,
112, 150, 149, 151, 189, 164, 198, 152, 165, 176,
169, 167, 175, 190, 171, 170, 20, -58, 196, 186,
177, 211, 192, 203, 37, 191, 205, 189, 194, 193,
200, 214, 223, 256, 224, 229, 190, 217, 227, 127,
221, 127, 51, 232, 52, 53, 54, 55, 56, 57,
58, 243, 233, 103, 59, 205, 234, 8, 9, 10,
11, 12, 13, 14, 15, 16, 17, 18, 19, 20,
238, 245, 240, 253, 47, 112, 225, 210, 231, 129,
243, 217, 252, 195, 213, 221, 260, 61, 168, 62,
199, 239, 21, 8, 9, 10, 11, 12, 13, 14,
15, 16, 17, 18, 19, 20, 259, 247, 0, 228,
261, 0, 180, 0, 0, 0, 0, 22, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 21, 8,
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
9, 10, 11, 12, 13, 14, 15, 16, 17, 18,
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
19, 20, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 22, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 21, 8, 9, 10, 11, 12,
13, 14, 15, 16, 17, 18, 19, 20, 0, 0,
0, 0, 0, 0, 0, 0, 136, 20, 87, 88,
89, 90, 91, 92, 93, 94, 95, 96, 97, 98,
21, 0, 0, 0, 0, 0, 0, 0, 99, 0,
21, 100, 101, 0, 0, 0, 0, 0, 212, 0,
0, 0, 0, 0, 0, 0, 0, 102, 8, 9,
10, 11, 12, 13, 14, 15, 16, 17, 18, 19,
20, 0, 87, 88, 89, 90, 91, 92, 93, 94,
95, 96, 97, 98, 0, 0, 0, 0, 0, 0,
0, 0, 0, 21
moving to trunk subdir
2010-06-03 21:24:43 +08:00
};
static const yytype_int16 yycheck[] =
{
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
22, 41, 46, 102, 25, 149, 39, 135, 16, 39,
45, 42, 43, 39, 21, 16, 38, 116, 25, 16,
120, 31, 122, 123, 46, 47, 125, 38, 50, 61,
63, 59, 64, 63, 62, 43, 55, 63, 3, 61,
73, 42, 39, 51, 52, 53, 57, 67, 68, 69,
71, 73, 151, 152, 0, 64, 21, 22, 102, 33,
25, 26, 17, 191, 208, 193, 21, 22, 56, 58,
25, 26, 116, 21, 22, 60, 59, 25, 26, 62,
102, 125, 59, 118, 119, 62, 117, 57, 60, 59,
121, 60, 60, 124, 116, 57, 60, 59, 64, 29,
17, 16, 60, 125, 148, 138, 60, 151, 152, 60,
60, 60, 145, 135, 61, 145, 138, 60, 60, 60,
60, 60, 58, 35, 58, 30, 148, 59, 227, 151,
152, 56, 61, 60, 164, 56, 171, 60, 21, 172,
58, 63, 172, 164, 60, 59, 16, 60, 170, 59,
32, 186, 56, 175, 175, 62, 177, 187, 58, 62,
58, 58, 58, 57, 59, 58, 187, 189, 60, 191,
192, 193, 42, 58, 44, 45, 46, 47, 48, 49,
50, 225, 59, 227, 54, 206, 61, 4, 5, 6,
7, 8, 9, 10, 11, 12, 13, 14, 15, 16,
60, 58, 224, 238, 38, 227, 61, 183, 210, 63,
254, 233, 237, 170, 187, 237, 256, 34, 138, 36,
172, 224, 39, 4, 5, 6, 7, 8, 9, 10,
11, 12, 13, 14, 15, 16, 254, 233, -1, 206,
257, -1, 148, -1, -1, -1, -1, 64, -1, -1,
-1, -1, -1, -1, -1, -1, -1, -1, 39, 4,
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
5, 6, 7, 8, 9, 10, 11, 12, 13, 14,
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
15, 16, -1, -1, -1, -1, -1, -1, -1, -1,
-1, -1, -1, 64, -1, -1, -1, -1, -1, -1,
-1, -1, -1, -1, 39, 4, 5, 6, 7, 8,
9, 10, 11, 12, 13, 14, 15, 16, -1, -1,
-1, -1, -1, -1, -1, -1, 61, 16, 17, 18,
19, 20, 21, 22, 23, 24, 25, 26, 27, 28,
39, -1, -1, -1, -1, -1, -1, -1, 37, -1,
39, 40, 41, -1, -1, -1, -1, -1, 57, -1,
-1, -1, -1, -1, -1, -1, -1, 56, 4, 5,
6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
16, -1, 17, 18, 19, 20, 21, 22, 23, 24,
25, 26, 27, 28, -1, -1, -1, -1, -1, -1,
-1, -1, -1, 39
moving to trunk subdir
2010-06-03 21:24:43 +08:00
};
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
/* YYSTOS[STATE-NUM] -- The (internal number of the) accessing
symbol of state STATE-NUM. */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
static const yytype_uint8 yystos[] =
{
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
0, 31, 66, 55, 67, 0, 56, 68, 4, 5,
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
16, 39, 64, 69, 88, 110, 111, 112, 113, 114,
131, 43, 51, 52, 53, 131, 70, 111, 64, 33,
74, 58, 60, 60, 60, 60, 60, 38, 57, 71,
64, 42, 44, 45, 46, 47, 48, 49, 50, 54,
131, 34, 36, 75, 77, 78, 80, 83, 84, 85,
88, 110, 113, 29, 89, 112, 17, 129, 129, 21,
22, 25, 26, 128, 129, 130, 128, 17, 18, 19,
20, 21, 22, 23, 24, 25, 26, 27, 28, 37,
40, 41, 56, 114, 118, 119, 120, 121, 122, 123,
124, 126, 131, 131, 42, 131, 60, 60, 60, 60,
60, 60, 60, 60, 60, 60, 76, 131, 61, 77,
58, 79, 79, 79, 79, 35, 61, 58, 90, 91,
92, 93, 94, 113, 131, 30, 95, 118, 59, 61,
56, 60, 60, 118, 129, 127, 128, 128, 130, 129,
130, 130, 129, 118, 56, 21, 76, 63, 91, 58,
59, 60, 96, 97, 98, 110, 113, 32, 115, 57,
121, 125, 126, 72, 118, 118, 59, 86, 87, 110,
111, 62, 56, 62, 58, 93, 131, 3, 128, 97,
58, 99, 100, 131, 109, 111, 116, 117, 59, 62,
69, 128, 57, 87, 58, 104, 105, 131, 76, 81,
82, 131, 76, 58, 59, 61, 101, 60, 117, 58,
126, 70, 58, 59, 61, 106, 57, 59, 60, 100,
131, 102, 103, 114, 118, 58, 73, 105, 21, 25,
107, 108, 82, 128, 59, 62, 57, 59, 62, 103,
112, 108
moving to trunk subdir
2010-06-03 21:24:43 +08:00
};
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
/* YYR1[YYN] -- Symbol number of symbol that rule YYN derives. */
static const yytype_uint8 yyr1[] =
{
0, 65, 66, 67, 68, 69, 70, 70, 72, 73,
71, 74, 74, 74, 75, 75, 76, 77, 77, 78,
78, 78, 78, 79, 79, 80, 81, 81, 82, 83,
84, 85, 86, 86, 87, 88, 88, 88, 88, 88,
88, 88, 88, 88, 88, 88, 88, 89, 89, 89,
90, 90, 91, 91, 92, 92, 93, 93, 94, 95,
95, 95, 96, 96, 97, 97, 98, 99, 99, 100,
101, 101, 102, 102, 103, 104, 104, 105, 106, 106,
107, 107, 108, 108, 109, 110, 111, 111, 112, 112,
113, 113, 113, 113, 113, 113, 113, 113, 113, 113,
113, 113, 113, 113, 113, 113, 113, 114, 114, 115,
115, 115, 116, 116, 117, 118, 118, 119, 120, 120,
121, 121, 122, 122, 122, 122, 122, 122, 123, 124,
125, 125, 126, 126, 126, 126, 126, 126, 126, 126,
126, 126, 126, 126, 127, 127, 128, 128, 128, 128,
129, 130, 130, 131
};
/* YYR2[YYN] -- Number of symbols on the right hand side of rule YYN. */
static const yytype_uint8 yyr2[] =
{
0, 2, 3, 1, 4, 5, 0, 2, 0, 0,
9, 0, 1, 2, 1, 2, 1, 1, 2, 2,
2, 2, 2, 0, 1, 6, 1, 3, 3, 5,
5, 5, 2, 3, 2, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 0, 1, 2,
2, 3, 1, 1, 1, 3, 3, 3, 1, 0,
1, 2, 2, 3, 1, 1, 2, 1, 3, 2,
0, 3, 1, 3, 1, 1, 3, 2, 0, 3,
1, 3, 1, 1, 1, 1, 1, 1, 0, 3,
4, 4, 4, 4, 6, 5, 5, 6, 5, 5,
5, 5, 5, 5, 5, 5, 4, 1, 1, 0,
1, 2, 2, 3, 3, 1, 1, 0, 1, 3,
1, 3, 1, 1, 1, 1, 1, 1, 1, 4,
1, 3, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 3, 1, 1, 1, 1,
1, 1, 1, 1
};
Add provenance info for netcdf-4 files. This consists of a persistent attribute named _NCProperties plus two computed attributes _IsNetcdf4 and _SuperblockVersion. See the 'Provenance Attributes' section of docs/attribute_conventions.md for details.
2016-05-04 11:17:06 +08:00
Moved libsrc5 to libsrcp because pnetcdf is used for more than CDF-5 files.
2015-08-15 10:38:30 +08:00
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
#define yyerrok (yyerrstatus = 0)
#define yyclearin (yychar = YYEMPTY)
#define YYEMPTY (-2)
#define YYEOF 0
[NCF-271] Fix bug introduced by [NCF-267]. The bug was that octal constants that had the highest bit set (e.g. '\200') were not recognized as proper octal constants. Fix was to keep as integer until it was needed as an 8-bit byte.
2013-09-27 00:10:26 +08:00
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
#define YYACCEPT goto yyacceptlab
#define YYABORT goto yyabortlab
#define YYERROR goto yyerrorlab
[NCF-271] Fix bug introduced by [NCF-267]. The bug was that octal constants that had the highest bit set (e.g. '\200') were not recognized as proper octal constants. Fix was to keep as integer until it was needed as an 8-bit byte.
2013-09-27 00:10:26 +08:00
moving to trunk subdir
2010-06-03 21:24:43 +08:00
Resolves Github issue https://github.com/Unidata/netcdf-c/issues/349. Update utf8proc.[ch] to use the version now maintained by the Julia Language project (https://github.com/JuliaLang/utf8proc/blob/master/LICENSE.md). The license for the previous version was unacceptable for the Debian and Ubuntu release systems. The new version both updates the code and addresses the license issue. It turns out that the utf8proc software we are using was turned over to the Julia Language developers and the license terms changed to allow modification. (https://github.com/JuliaLang/utf8proc/blob/master/LICENSE.md). So the fix here is as follows: 1. Wrap the library with a fixed interface: libdispatch/dutf8.c and include/ncutf8.h. 2. Replace the existing utf8proc code with the new version from https://github.com/JuliaLang/utf8proc. 3. Add a couple more test cases: nc_test/tst_utf8_validate.c and nc_test_utf8_phrases.c. If/when I can find a usable normalization test, I will incorporate that later.
2017-02-17 05:27:54 +08:00
#define YYRECOVERING() (!!yyerrstatus)
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
#define YYBACKUP(Token, Value) \
do \
if (yychar == YYEMPTY) \
{ \
yychar = (Token); \
yylval = (Value); \
YYPOPSTACK (yylen); \
yystate = *yyssp; \
goto yybackup; \
} \
else \
{ \
Resolves Github issue https://github.com/Unidata/netcdf-c/issues/349. Update utf8proc.[ch] to use the version now maintained by the Julia Language project (https://github.com/JuliaLang/utf8proc/blob/master/LICENSE.md). The license for the previous version was unacceptable for the Debian and Ubuntu release systems. The new version both updates the code and addresses the license issue. It turns out that the utf8proc software we are using was turned over to the Julia Language developers and the license terms changed to allow modification. (https://github.com/JuliaLang/utf8proc/blob/master/LICENSE.md). So the fix here is as follows: 1. Wrap the library with a fixed interface: libdispatch/dutf8.c and include/ncutf8.h. 2. Replace the existing utf8proc code with the new version from https://github.com/JuliaLang/utf8proc. 3. Add a couple more test cases: nc_test/tst_utf8_validate.c and nc_test_utf8_phrases.c. If/when I can find a usable normalization test, I will incorporate that later.
2017-02-17 05:27:54 +08:00
yyerror (YY_("syntax error: cannot back up")); \
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
YYERROR; \
} \
while (0)
Merge branch 'master' into filters.dmh
2017-11-14 02:15:02 +08:00
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
/* Error token number */
#define YYTERROR 1
#define YYERRCODE 256
Resolves Github issue https://github.com/Unidata/netcdf-c/issues/349. Update utf8proc.[ch] to use the version now maintained by the Julia Language project (https://github.com/JuliaLang/utf8proc/blob/master/LICENSE.md). The license for the previous version was unacceptable for the Debian and Ubuntu release systems. The new version both updates the code and addresses the license issue. It turns out that the utf8proc software we are using was turned over to the Julia Language developers and the license terms changed to allow modification. (https://github.com/JuliaLang/utf8proc/blob/master/LICENSE.md). So the fix here is as follows: 1. Wrap the library with a fixed interface: libdispatch/dutf8.c and include/ncutf8.h. 2. Replace the existing utf8proc code with the new version from https://github.com/JuliaLang/utf8proc. 3. Add a couple more test cases: nc_test/tst_utf8_validate.c and nc_test_utf8_phrases.c. If/when I can find a usable normalization test, I will incorporate that later.
2017-02-17 05:27:54 +08:00
moving to trunk subdir
2010-06-03 21:24:43 +08:00
/* Enable debugging if requested. */
#if YYDEBUG
# ifndef YYFPRINTF
# include <stdio.h> /* INFRINGES ON USER NAME SPACE */
# define YYFPRINTF fprintf
# endif
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
# define YYDPRINTF(Args) \
do { \
if (yydebug) \
YYFPRINTF Args; \
} while (0)
/* This macro is provided for backward compatibility. */
#ifndef YY_LOCATION_PRINT
# define YY_LOCATION_PRINT(File, Loc) ((void) 0)
#endif
Primary change: add dap4 support Specific changes: 1. Add dap4 code: libdap4 and dap4_test. Note that until the d4ts server problem is solved, dap4 is turned off. 2. Modify various files to support dap4 flags: configure.ac, Makefile.am, CMakeLists.txt, etc. 3. Add nc_test/test_common.sh. This centralizes the handling of the locations of various things in the build tree: e.g. where is ncgen.exe located. See nc_test/test_common.sh for details. 4. Modify .sh files to use test_common.sh 5. Obsolete separate oc2 by moving it to be part of netcdf-c. This means replacing code with netcdf-c equivalents. 5. Add --with-testserver to configure.ac to allow override of the servers to be used for --enable-dap-remote-tests. 6. There were multiple versions of nctypealignment code. Try to centralize in libdispatch/doffset.c and include/ncoffsets.h 7. Add a unit test for the ncuri code because of its complexity. 8. Move the findserver code out of libdispatch and into a separate, self contained program in ncdap_test and dap4_test. 9. Move the dispatch header files (nc{3,4}dispatch.h) to .../include because they are now shared by modules. 10. Revamp the handling of TOPSRCDIR and TOPBUILDDIR for shell scripts. 11. Make use of MREMAP if available 12. Misc. minor changes e.g. - #include <config.h> -> #include "config.h" - Add some no-install headers to /include - extern -> EXTERNL and vice versa as needed - misc header cleanup - clean up checking for misc. unix vs microsoft functions 13. Change copyright decls in some files to point to LICENSE file. 14. Add notes to RELEASENOTES.md
2017-03-09 08:01:10 +08:00
Add provenance info for netcdf-4 files. This consists of a persistent attribute named _NCProperties plus two computed attributes _IsNetcdf4 and _SuperblockVersion. See the 'Provenance Attributes' section of docs/attribute_conventions.md for details.
2016-05-04 11:17:06 +08:00
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
# define YY_SYMBOL_PRINT(Title, Type, Value, Location) \
do { \
if (yydebug) \
{ \
YYFPRINTF (stderr, "%s ", Title); \
yy_symbol_print (stderr, \
Type, Value); \
YYFPRINTF (stderr, "\n"); \
} \
} while (0)
Resolves Github issue https://github.com/Unidata/netcdf-c/issues/349. Update utf8proc.[ch] to use the version now maintained by the Julia Language project (https://github.com/JuliaLang/utf8proc/blob/master/LICENSE.md). The license for the previous version was unacceptable for the Debian and Ubuntu release systems. The new version both updates the code and addresses the license issue. It turns out that the utf8proc software we are using was turned over to the Julia Language developers and the license terms changed to allow modification. (https://github.com/JuliaLang/utf8proc/blob/master/LICENSE.md). So the fix here is as follows: 1. Wrap the library with a fixed interface: libdispatch/dutf8.c and include/ncutf8.h. 2. Replace the existing utf8proc code with the new version from https://github.com/JuliaLang/utf8proc. 3. Add a couple more test cases: nc_test/tst_utf8_validate.c and nc_test_utf8_phrases.c. If/when I can find a usable normalization test, I will incorporate that later.
2017-02-17 05:27:54 +08:00
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
/*----------------------------------------.
| Print this symbol's value on YYOUTPUT. |
`----------------------------------------*/
moving to trunk subdir
2010-06-03 21:24:43 +08:00
static void
yy_symbol_value_print (FILE *yyoutput, int yytype, YYSTYPE const * const yyvaluep)
{
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
FILE *yyo = yyoutput;
YYUSE (yyo);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
if (!yyvaluep)
return;
# ifdef YYPRINT
if (yytype < YYNTOKENS)
YYPRINT (yyoutput, yytoknum[yytype], *yyvaluep);
# endif
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
YYUSE (yytype);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
}
/*--------------------------------.
| Print this symbol on YYOUTPUT. |
`--------------------------------*/
static void
yy_symbol_print (FILE *yyoutput, int yytype, YYSTYPE const * const yyvaluep)
{
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
YYFPRINTF (yyoutput, "%s %s (",
yytype < YYNTOKENS ? "token" : "nterm", yytname[yytype]);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
yy_symbol_value_print (yyoutput, yytype, yyvaluep);
YYFPRINTF (yyoutput, ")");
}
/*------------------------------------------------------------------.
| yy_stack_print -- Print the state stack from its BOTTOM up to its |
| TOP (included). |
`------------------------------------------------------------------*/
static void
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
yy_stack_print (yytype_int16 *yybottom, yytype_int16 *yytop)
moving to trunk subdir
2010-06-03 21:24:43 +08:00
{
YYFPRINTF (stderr, "Stack now");
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
for (; yybottom <= yytop; yybottom++)
{
int yybot = *yybottom;
YYFPRINTF (stderr, " %d", yybot);
}
moving to trunk subdir
2010-06-03 21:24:43 +08:00
YYFPRINTF (stderr, "\n");
}
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
# define YY_STACK_PRINT(Bottom, Top) \
do { \
if (yydebug) \
yy_stack_print ((Bottom), (Top)); \
} while (0)
moving to trunk subdir
2010-06-03 21:24:43 +08:00
/*------------------------------------------------.
| Report that the YYRULE is going to be reduced. |
`------------------------------------------------*/
Attempting to fix visual studio errors in support of https://github.com/Unidata/netcdf-c/pull/375
2017-03-14 05:12:47 +08:00
static void
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
yy_reduce_print (yytype_int16 *yyssp, YYSTYPE *yyvsp, int yyrule)
moving to trunk subdir
2010-06-03 21:24:43 +08:00
{
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
unsigned long int yylno = yyrline[yyrule];
moving to trunk subdir
2010-06-03 21:24:43 +08:00
int yynrhs = yyr2[yyrule];
int yyi;
YYFPRINTF (stderr, "Reducing stack by rule %d (line %lu):\n",
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
yyrule - 1, yylno);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
/* The symbols being reduced. */
for (yyi = 0; yyi < yynrhs; yyi++)
{
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
YYFPRINTF (stderr, " $%d = ", yyi + 1);
yy_symbol_print (stderr,
yystos[yyssp[yyi + 1 - yynrhs]],
&(yyvsp[(yyi + 1) - (yynrhs)])
);
YYFPRINTF (stderr, "\n");
moving to trunk subdir
2010-06-03 21:24:43 +08:00
}
}
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
# define YY_REDUCE_PRINT(Rule) \
do { \
if (yydebug) \
yy_reduce_print (yyssp, yyvsp, Rule); \
} while (0)
moving to trunk subdir
2010-06-03 21:24:43 +08:00
/* Nonzero means print parse trace. It is left uninitialized so that
multiple parsers can coexist. */
int yydebug;
#else /* !YYDEBUG */
# define YYDPRINTF(Args)
# define YY_SYMBOL_PRINT(Title, Type, Value, Location)
# define YY_STACK_PRINT(Bottom, Top)
# define YY_REDUCE_PRINT(Rule)
#endif /* !YYDEBUG */
/* YYINITDEPTH -- initial size of the parser's stacks. */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
#ifndef YYINITDEPTH
moving to trunk subdir
2010-06-03 21:24:43 +08:00
# define YYINITDEPTH 200
#endif
/* YYMAXDEPTH -- maximum size the stacks can grow to (effective only
if the built-in stack extension method is used).
Do not make this value too large; the results are undefined if
YYSTACK_ALLOC_MAXIMUM < YYSTACK_BYTES (YYMAXDEPTH)
evaluated with infinite-precision integer arithmetic. */
#ifndef YYMAXDEPTH
# define YYMAXDEPTH 10000
#endif
#if YYERROR_VERBOSE
# ifndef yystrlen
# if defined __GLIBC__ && defined _STRING_H
# define yystrlen strlen
# else
/* Return the length of YYSTR. */
static YYSIZE_T
yystrlen (const char *yystr)
{
YYSIZE_T yylen;
for (yylen = 0; yystr[yylen]; yylen++)
continue;
return yylen;
}
# endif
# endif
# ifndef yystpcpy
# if defined __GLIBC__ && defined _STRING_H && defined _GNU_SOURCE
# define yystpcpy stpcpy
# else
/* Copy YYSRC to YYDEST, returning the address of the terminating '\0' in
YYDEST. */
static char *
yystpcpy (char *yydest, const char *yysrc)
{
char *yyd = yydest;
const char *yys = yysrc;
while ((*yyd++ = *yys++) != '\0')
continue;
return yyd - 1;
}
# endif
# endif
# ifndef yytnamerr
/* Copy to YYRES the contents of YYSTR after stripping away unnecessary
quotes and backslashes, so that it's suitable for yyerror. The
heuristic is that double-quoting is unnecessary unless the string
contains an apostrophe, a comma, or backslash (other than
backslash-backslash). YYSTR is taken from yytname. If YYRES is
null, do not copy; instead, return the length of what the result
would have been. */
static YYSIZE_T
yytnamerr (char *yyres, const char *yystr)
{
if (*yystr == '"')
{
YYSIZE_T yyn = 0;
char const *yyp = yystr;
for (;;)
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
switch (*++yyp)
{
case '\'':
case ',':
goto do_not_strip_quotes;
case '\\':
if (*++yyp != '\\')
goto do_not_strip_quotes;
/* Fall through. */
default:
if (yyres)
yyres[yyn] = *yyp;
yyn++;
break;
case '"':
if (yyres)
yyres[yyn] = '\0';
return yyn;
}
moving to trunk subdir
2010-06-03 21:24:43 +08:00
do_not_strip_quotes: ;
}
if (! yyres)
return yystrlen (yystr);
return yystpcpy (yyres, yystr) - yyres;
}
# endif
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
/* Copy into *YYMSG, which is of size *YYMSG_ALLOC, an error message
about the unexpected token YYTOKEN for the state stack whose top is
YYSSP.
Return 0 if *YYMSG was successfully written. Return 1 if *YYMSG is
not large enough to hold the message. In that case, also set
*YYMSG_ALLOC to the required number of bytes. Return 2 if the
required number of bytes is too large to store. */
static int
yysyntax_error (YYSIZE_T *yymsg_alloc, char **yymsg,
yytype_int16 *yyssp, int yytoken)
1. There were several bugs in ncdump/dumplib.c that were not taking the CDF-5 format into account. 2. Had to update ncgen.1 man page to define the new k-flag rules to deal with cdf-5. 3. Had to fix some tests that use 'cmp' for comparison; this really should be deprecated. 3. There was a bug in configure.ac with respect to using the enable-netcdf-4 flag vs using disable-netcdf-4.
2015-11-07 08:03:28 +08:00
{
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
YYSIZE_T yysize0 = yytnamerr (YY_NULLPTR, yytname[yytoken]);
YYSIZE_T yysize = yysize0;
enum { YYERROR_VERBOSE_ARGS_MAXIMUM = 5 };
/* Internationalized format string. */
const char *yyformat = YY_NULLPTR;
/* Arguments of yyformat. */
char const *yyarg[YYERROR_VERBOSE_ARGS_MAXIMUM];
/* Number of reported tokens (one for the "unexpected", one per
"expected"). */
int yycount = 0;
/* There are many possibilities here to consider:
- If this state is a consistent state with a default action, then
the only way this function was invoked is if the default action
is an error action. In that case, don't check for expected
tokens because there are none.
- The only way there can be no lookahead present (in yychar) is if
this state is a consistent state with a default action. Thus,
detecting the absence of a lookahead is sufficient to determine
that there is no unexpected or expected token to report. In that
case, just report a simple "syntax error".
- Don't assume there isn't a lookahead just because this state is a
consistent state with a default action. There might have been a
previous inconsistent state, consistent state with a non-default
action, or user semantic action that manipulated yychar.
- Of course, the expected token list depends on states to have
correct lookahead information, and it depends on the parser not
to perform extra reductions after fetching a lookahead from the
scanner and before detecting a syntax error. Thus, state merging
(from LALR or IELR) and default reductions corrupt the expected
token list. However, the list is correct for canonical LR with
one exception: it will still contain any token that will not be
accepted due to an error action in a later state.
*/
if (yytoken != YYEMPTY)
{
int yyn = yypact[*yyssp];
yyarg[yycount++] = yytname[yytoken];
if (!yypact_value_is_default (yyn))
{
/* Start YYX at -YYN if negative to avoid negative indexes in
YYCHECK. In other words, skip the first -YYN actions for
this state because they are default actions. */
int yyxbegin = yyn < 0 ? -yyn : 0;
/* Stay within bounds of both yycheck and yytname. */
int yychecklim = YYLAST - yyn + 1;
int yyxend = yychecklim < YYNTOKENS ? yychecklim : YYNTOKENS;
int yyx;
for (yyx = yyxbegin; yyx < yyxend; ++yyx)
if (yycheck[yyx + yyn] == yyx && yyx != YYTERROR
&& !yytable_value_is_error (yytable[yyx + yyn]))
{
if (yycount == YYERROR_VERBOSE_ARGS_MAXIMUM)
{
yycount = 1;
yysize = yysize0;
break;
}
yyarg[yycount++] = yytname[yyx];
{
YYSIZE_T yysize1 = yysize + yytnamerr (YY_NULLPTR, yytname[yyx]);
if (! (yysize <= yysize1
&& yysize1 <= YYSTACK_ALLOC_MAXIMUM))
return 2;
yysize = yysize1;
}
}
}
}
Add provenance info for netcdf-4 files. This consists of a persistent attribute named _NCProperties plus two computed attributes _IsNetcdf4 and _SuperblockVersion. See the 'Provenance Attributes' section of docs/attribute_conventions.md for details.
2016-05-04 11:17:06 +08:00
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
switch (yycount)
Primary change: add dap4 support Specific changes: 1. Add dap4 code: libdap4 and dap4_test. Note that until the d4ts server problem is solved, dap4 is turned off. 2. Modify various files to support dap4 flags: configure.ac, Makefile.am, CMakeLists.txt, etc. 3. Add nc_test/test_common.sh. This centralizes the handling of the locations of various things in the build tree: e.g. where is ncgen.exe located. See nc_test/test_common.sh for details. 4. Modify .sh files to use test_common.sh 5. Obsolete separate oc2 by moving it to be part of netcdf-c. This means replacing code with netcdf-c equivalents. 5. Add --with-testserver to configure.ac to allow override of the servers to be used for --enable-dap-remote-tests. 6. There were multiple versions of nctypealignment code. Try to centralize in libdispatch/doffset.c and include/ncoffsets.h 7. Add a unit test for the ncuri code because of its complexity. 8. Move the findserver code out of libdispatch and into a separate, self contained program in ncdap_test and dap4_test. 9. Move the dispatch header files (nc{3,4}dispatch.h) to .../include because they are now shared by modules. 10. Revamp the handling of TOPSRCDIR and TOPBUILDDIR for shell scripts. 11. Make use of MREMAP if available 12. Misc. minor changes e.g. - #include <config.h> -> #include "config.h" - Add some no-install headers to /include - extern -> EXTERNL and vice versa as needed - misc header cleanup - clean up checking for misc. unix vs microsoft functions 13. Change copyright decls in some files to point to LICENSE file. 14. Add notes to RELEASENOTES.md
2017-03-09 08:01:10 +08:00
{
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
# define YYCASE_(N, S) \
case N: \
yyformat = S; \
break
YYCASE_(0, YY_("syntax error"));
YYCASE_(1, YY_("syntax error, unexpected %s"));
YYCASE_(2, YY_("syntax error, unexpected %s, expecting %s"));
YYCASE_(3, YY_("syntax error, unexpected %s, expecting %s or %s"));
YYCASE_(4, YY_("syntax error, unexpected %s, expecting %s or %s or %s"));
YYCASE_(5, YY_("syntax error, unexpected %s, expecting %s or %s or %s or %s"));
# undef YYCASE_
Primary change: add dap4 support Specific changes: 1. Add dap4 code: libdap4 and dap4_test. Note that until the d4ts server problem is solved, dap4 is turned off. 2. Modify various files to support dap4 flags: configure.ac, Makefile.am, CMakeLists.txt, etc. 3. Add nc_test/test_common.sh. This centralizes the handling of the locations of various things in the build tree: e.g. where is ncgen.exe located. See nc_test/test_common.sh for details. 4. Modify .sh files to use test_common.sh 5. Obsolete separate oc2 by moving it to be part of netcdf-c. This means replacing code with netcdf-c equivalents. 5. Add --with-testserver to configure.ac to allow override of the servers to be used for --enable-dap-remote-tests. 6. There were multiple versions of nctypealignment code. Try to centralize in libdispatch/doffset.c and include/ncoffsets.h 7. Add a unit test for the ncuri code because of its complexity. 8. Move the findserver code out of libdispatch and into a separate, self contained program in ncdap_test and dap4_test. 9. Move the dispatch header files (nc{3,4}dispatch.h) to .../include because they are now shared by modules. 10. Revamp the handling of TOPSRCDIR and TOPBUILDDIR for shell scripts. 11. Make use of MREMAP if available 12. Misc. minor changes e.g. - #include <config.h> -> #include "config.h" - Add some no-install headers to /include - extern -> EXTERNL and vice versa as needed - misc header cleanup - clean up checking for misc. unix vs microsoft functions 13. Change copyright decls in some files to point to LICENSE file. 14. Add notes to RELEASENOTES.md
2017-03-09 08:01:10 +08:00
}
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{
YYSIZE_T yysize1 = yysize + yystrlen (yyformat);
if (! (yysize <= yysize1 && yysize1 <= YYSTACK_ALLOC_MAXIMUM))
return 2;
yysize = yysize1;
}
if (*yymsg_alloc < yysize)
{
*yymsg_alloc = 2 * yysize;
if (! (yysize <= *yymsg_alloc
&& *yymsg_alloc <= YYSTACK_ALLOC_MAXIMUM))
*yymsg_alloc = YYSTACK_ALLOC_MAXIMUM;
return 1;
}
/* Avoid sprintf, as that infringes on the user's name space.
Don't have undefined behavior even if the translation
produced a string with the wrong number of "%s"s. */
{
char *yyp = *yymsg;
int yyi = 0;
while ((*yyp = *yyformat) != '\0')
if (*yyp == '%' && yyformat[1] == 's' && yyi < yycount)
{
yyp += yytnamerr (yyp, yyarg[yyi++]);
yyformat += 2;
}
else
{
yyp++;
yyformat++;
}
}
return 0;
moving to trunk subdir
2010-06-03 21:24:43 +08:00
}
#endif /* YYERROR_VERBOSE */
/*-----------------------------------------------.
| Release the memory associated to this symbol. |
`-----------------------------------------------*/
static void
yydestruct (const char *yymsg, int yytype, YYSTYPE *yyvaluep)
{
YYUSE (yyvaluep);
if (!yymsg)
yymsg = "Deleting";
YY_SYMBOL_PRINT (yymsg, yytype, yyvaluep, yylocationp);
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
YY_IGNORE_MAYBE_UNINITIALIZED_BEGIN
YYUSE (yytype);
YY_IGNORE_MAYBE_UNINITIALIZED_END
Added a tweak to prevent problems with ncdump and hdf5 trying to correct for a lack of ssize_t.
2016-05-11 05:52:46 +08:00
}
Addressed an API-related usage of strncmp.
2015-11-25 07:19:36 +08:00
moving to trunk subdir
2010-06-03 21:24:43 +08:00
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
/* The lookahead symbol. */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
int yychar;
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
/* The semantic value of the lookahead symbol. */
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
YYSTYPE yylval;
moving to trunk subdir
2010-06-03 21:24:43 +08:00
/* Number of syntax errors so far. */
int yynerrs;
Resolves Github issue https://github.com/Unidata/netcdf-c/issues/349. Update utf8proc.[ch] to use the version now maintained by the Julia Language project (https://github.com/JuliaLang/utf8proc/blob/master/LICENSE.md). The license for the previous version was unacceptable for the Debian and Ubuntu release systems. The new version both updates the code and addresses the license issue. It turns out that the utf8proc software we are using was turned over to the Julia Language developers and the license terms changed to allow modification. (https://github.com/JuliaLang/utf8proc/blob/master/LICENSE.md). So the fix here is as follows: 1. Wrap the library with a fixed interface: libdispatch/dutf8.c and include/ncutf8.h. 2. Replace the existing utf8proc code with the new version from https://github.com/JuliaLang/utf8proc. 3. Add a couple more test cases: nc_test/tst_utf8_validate.c and nc_test_utf8_phrases.c. If/when I can find a usable normalization test, I will incorporate that later.
2017-02-17 05:27:54 +08:00
/*----------.
| yyparse. |
`----------*/
moving to trunk subdir
2010-06-03 21:24:43 +08:00
int
yyparse (void)
Merge branch 'master' into filters.dmh
2017-11-14 02:15:02 +08:00
{
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
int yystate;
/* Number of tokens to shift before error messages enabled. */
int yyerrstatus;
/* The stacks and their tools:
'yyss': related to states.
'yyvs': related to semantic values.
Refer to the stacks through separate pointers, to allow yyoverflow
to reallocate them elsewhere. */
/* The state stack. */
yytype_int16 yyssa[YYINITDEPTH];
yytype_int16 *yyss;
yytype_int16 *yyssp;
/* The semantic value stack. */
YYSTYPE yyvsa[YYINITDEPTH];
YYSTYPE *yyvs;
YYSTYPE *yyvsp;
YYSIZE_T yystacksize;
Working out an error with unistd.h in windows.
2017-01-31 05:54:00 +08:00
int yyn;
int yyresult;
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
/* Lookahead token as an internal (translated) token number. */
Resolves Github issue https://github.com/Unidata/netcdf-c/issues/349. Update utf8proc.[ch] to use the version now maintained by the Julia Language project (https://github.com/JuliaLang/utf8proc/blob/master/LICENSE.md). The license for the previous version was unacceptable for the Debian and Ubuntu release systems. The new version both updates the code and addresses the license issue. It turns out that the utf8proc software we are using was turned over to the Julia Language developers and the license terms changed to allow modification. (https://github.com/JuliaLang/utf8proc/blob/master/LICENSE.md). So the fix here is as follows: 1. Wrap the library with a fixed interface: libdispatch/dutf8.c and include/ncutf8.h. 2. Replace the existing utf8proc code with the new version from https://github.com/JuliaLang/utf8proc. 3. Add a couple more test cases: nc_test/tst_utf8_validate.c and nc_test_utf8_phrases.c. If/when I can find a usable normalization test, I will incorporate that later.
2017-02-17 05:27:54 +08:00
int yytoken = 0;
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
/* The variables used to return semantic value and location from the
action routines. */
YYSTYPE yyval;
Working out an error with unistd.h in windows.
2017-01-31 05:54:00 +08:00
#if YYERROR_VERBOSE
/* Buffer for error messages, and its allocated size. */
char yymsgbuf[128];
char *yymsg = yymsgbuf;
YYSIZE_T yymsg_alloc = sizeof yymsgbuf;
#endif
#define YYPOPSTACK(N) (yyvsp -= (N), yyssp -= (N))
merge-squash
2015-08-16 06:26:35 +08:00
moving to trunk subdir
2010-06-03 21:24:43 +08:00
/* The number of symbols on the RHS of the reduced rule.
Keep to zero when no symbol should be popped. */
int yylen = 0;
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
yyssp = yyss = yyssa;
yyvsp = yyvs = yyvsa;
yystacksize = YYINITDEPTH;
moving to trunk subdir
2010-06-03 21:24:43 +08:00
YYDPRINTF ((stderr, "Starting parse\n"));
yystate = 0;
yyerrstatus = 0;
yynerrs = 0;
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
yychar = YYEMPTY; /* Cause a token to be read. */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
goto yysetstate;
/*------------------------------------------------------------.
| yynewstate -- Push a new state, which is found in yystate. |
`------------------------------------------------------------*/
yynewstate:
/* In all cases, when you get here, the value and location stacks
have just been pushed. So pushing a state here evens the stacks. */
yyssp++;
yysetstate:
*yyssp = yystate;
if (yyss + yystacksize - 1 <= yyssp)
{
/* Get the current used size of the three stacks, in elements. */
YYSIZE_T yysize = yyssp - yyss + 1;
#ifdef yyoverflow
{
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
/* Give user a chance to reallocate the stack. Use copies of
these so that the &'s don't force the real ones into
memory. */
YYSTYPE *yyvs1 = yyvs;
yytype_int16 *yyss1 = yyss;
/* Each stack pointer address is followed by the size of the
data in use in that stack, in bytes. This used to be a
conditional around just the two extra args, but that might
be undefined if yyoverflow is a macro. */
yyoverflow (YY_("memory exhausted"),
&yyss1, yysize * sizeof (*yyssp),
&yyvs1, yysize * sizeof (*yyvsp),
&yystacksize);
yyss = yyss1;
yyvs = yyvs1;
moving to trunk subdir
2010-06-03 21:24:43 +08:00
}
#else /* no yyoverflow */
# ifndef YYSTACK_RELOCATE
goto yyexhaustedlab;
# else
/* Extend the stack our own way. */
if (YYMAXDEPTH <= yystacksize)
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
goto yyexhaustedlab;
moving to trunk subdir
2010-06-03 21:24:43 +08:00
yystacksize *= 2;
if (YYMAXDEPTH < yystacksize)
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
yystacksize = YYMAXDEPTH;
moving to trunk subdir
2010-06-03 21:24:43 +08:00
{
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
yytype_int16 *yyss1 = yyss;
union yyalloc *yyptr =
(union yyalloc *) YYSTACK_ALLOC (YYSTACK_BYTES (yystacksize));
if (! yyptr)
goto yyexhaustedlab;
YYSTACK_RELOCATE (yyss_alloc, yyss);
YYSTACK_RELOCATE (yyvs_alloc, yyvs);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
# undef YYSTACK_RELOCATE
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
if (yyss1 != yyssa)
YYSTACK_FREE (yyss1);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
}
# endif
#endif /* no yyoverflow */
yyssp = yyss + yysize - 1;
yyvsp = yyvs + yysize - 1;
YYDPRINTF ((stderr, "Stack size increased to %lu\n",
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
(unsigned long int) yystacksize));
moving to trunk subdir
2010-06-03 21:24:43 +08:00
if (yyss + yystacksize - 1 <= yyssp)
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
YYABORT;
moving to trunk subdir
2010-06-03 21:24:43 +08:00
}
YYDPRINTF ((stderr, "Entering state %d\n", yystate));
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
if (yystate == YYFINAL)
YYACCEPT;
moving to trunk subdir
2010-06-03 21:24:43 +08:00
goto yybackup;
/*-----------.
| yybackup. |
`-----------*/
yybackup:
/* Do appropriate processing given the current state. Read a
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
lookahead token if we need one and don't already have one. */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
/* First try to decide what to do without reference to lookahead token. */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
yyn = yypact[yystate];
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
if (yypact_value_is_default (yyn))
moving to trunk subdir
2010-06-03 21:24:43 +08:00
goto yydefault;
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
/* Not known => get a lookahead token if don't already have one. */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
/* YYCHAR is either YYEMPTY or YYEOF or a valid lookahead symbol. */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
if (yychar == YYEMPTY)
{
YYDPRINTF ((stderr, "Reading a token: "));
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
yychar = yylex ();
moving to trunk subdir
2010-06-03 21:24:43 +08:00
}
if (yychar <= YYEOF)
{
yychar = yytoken = YYEOF;
YYDPRINTF ((stderr, "Now at end of input.\n"));
}
else
{
yytoken = YYTRANSLATE (yychar);
YY_SYMBOL_PRINT ("Next token is", yytoken, &yylval, &yylloc);
}
/* If the proper action on seeing token YYTOKEN is to reduce or to
detect an error, take that action. */
yyn += yytoken;
if (yyn < 0 || YYLAST < yyn || yycheck[yyn] != yytoken)
goto yydefault;
yyn = yytable[yyn];
if (yyn <= 0)
{
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
if (yytable_value_is_error (yyn))
goto yyerrlab;
moving to trunk subdir
2010-06-03 21:24:43 +08:00
yyn = -yyn;
goto yyreduce;
}
/* Count tokens shifted since error; after three, turn off error
status. */
if (yyerrstatus)
yyerrstatus--;
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
/* Shift the lookahead token. */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
YY_SYMBOL_PRINT ("Shifting", yytoken, &yylval, &yylloc);
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
/* Discard the shifted token. */
yychar = YYEMPTY;
moving to trunk subdir
2010-06-03 21:24:43 +08:00
yystate = yyn;
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
YY_IGNORE_MAYBE_UNINITIALIZED_BEGIN
moving to trunk subdir
2010-06-03 21:24:43 +08:00
*++yyvsp = yylval;
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
YY_IGNORE_MAYBE_UNINITIALIZED_END
moving to trunk subdir
2010-06-03 21:24:43 +08:00
goto yynewstate;
/*-----------------------------------------------------------.
| yydefault -- do the default action for the current state. |
`-----------------------------------------------------------*/
yydefault:
yyn = yydefact[yystate];
if (yyn == 0)
goto yyerrlab;
goto yyreduce;
/*-----------------------------.
| yyreduce -- Do a reduction. |
`-----------------------------*/
yyreduce:
/* yyn is the number of a rule to reduce with. */
yylen = yyr2[yyn];
/* If YYLEN is nonzero, implement the default value of the action:
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
'$$ = $1'.
moving to trunk subdir
2010-06-03 21:24:43 +08:00
Otherwise, the following line sets YYVAL to garbage.
This behavior is undocumented and Bison
users should not rely upon it. Assigning to YYVAL
unconditionally makes the parser a bit smaller, and it avoids a
GCC warning that YYVAL may be used uninitialized. */
yyval = yyvsp[1-yylen];
YY_REDUCE_PRINT (yyn);
switch (yyn)
{
case 2:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 234 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{if (error_count > 0) YYABORT;}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 1644 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
case 3:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 237 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{createrootgroup(datasetname);}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 1650 "ncgeny.c" /* yacc.c:1646 */
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
break;
case 8:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 256 "ncgen.y" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
{
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
Symbol* id = (yyvsp[-1].sym);
Fixed the following Jira minor bugs: NCF-42: _Format attribute sometimes being ignored NCF-43: Fixed unsigned long long parsing. NCF-47: Make opendap code properly handle illegal names like "x.y" by supressing them NCF-49: check for uint type NCF-50: properly handle username:pwd embedded in urls.
2011-05-13 01:51:32 +08:00
markcdf4("Group specification");
Addressed UNIX API issues reported by clang.
2015-06-19 04:31:10 +08:00
if(creategroup(id) == NULL)
moving to trunk subdir
2010-06-03 21:24:43 +08:00
yyerror("duplicate group declaration within parent group for %s",
disallow uppercase section keywords
2010-08-26 03:01:07 +08:00
id->name);
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 1662 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
case 9:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 265 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{listpop(groupstack);}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 1668 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
case 12:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 271 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 1674 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
case 13:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 273 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{markcdf4("Type specification");}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 1680 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
case 16:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 279 "ncgen.y" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
{ /* Use when defining a type */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
(yyvsp[0].sym)->objectclass = NC_TYPE;
if(dupobjectcheck(NC_TYPE,(yyvsp[0].sym)))
moving to trunk subdir
2010-06-03 21:24:43 +08:00
yyerror("duplicate type declaration for %s",
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
(yyvsp[0].sym)->name);
listpush(typdefs,(void*)(yyvsp[0].sym));
}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 1692 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
case 17:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 288 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 1698 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
case 18:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 288 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 1704 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
case 25:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 302 "ncgen.y" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
{
int i;
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
addtogroup((yyvsp[-3].sym)); /* sets prefix*/
(yyvsp[-3].sym)->objectclass=NC_TYPE;
(yyvsp[-3].sym)->subclass=NC_ENUM;
(yyvsp[-3].sym)->typ.basetype=(yyvsp[-5].sym);
(yyvsp[-3].sym)->typ.size = (yyvsp[-5].sym)->typ.size;
(yyvsp[-3].sym)->typ.alignment = (yyvsp[-5].sym)->typ.alignment;
stackbase=(yyvsp[-1].mark);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
stacklen=listlength(stack);
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
(yyvsp[-3].sym)->subnodes = listnew();
moving to trunk subdir
2010-06-03 21:24:43 +08:00
/* Variety of field fixups*/
/* 1. add in the enum values*/
/* 2. make this type be their container*/
/* 3. make constant names visible in the group*/
/* 4. set field basetype to be same as enum basetype*/
for(i=stackbase;i<stacklen;i++) {
Symbol* eid = (Symbol*)listget(stack,i);
assert(eid->subclass == NC_ECONST);
addtogroup(eid);
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
listpush((yyvsp[-3].sym)->subnodes,(void*)eid);
eid->container = (yyvsp[-3].sym);
eid->typ.basetype = (yyvsp[-3].sym)->typ.basetype;
Addressed UNIX API issues reported by clang.
2015-06-19 04:31:10 +08:00
}
moving to trunk subdir
2010-06-03 21:24:43 +08:00
listsetlength(stack,stackbase);/* remove stack nodes*/
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 1735 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
case 26:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 331 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.mark)=listlength(stack); listpush(stack,(void*)(yyvsp[0].sym));}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 1741 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
case 27:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 333 "ncgen.y" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
{
int i;
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
(yyval.mark)=(yyvsp[-2].mark);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
/* check for duplicates*/
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
stackbase=(yyvsp[-2].mark);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
stacklen=listlength(stack);
for(i=stackbase;i<stacklen;i++) {
Symbol* elem = (Symbol*)listget(stack,i);
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
if(strcmp((yyvsp[0].sym)->name,elem->name)==0)
moving to trunk subdir
2010-06-03 21:24:43 +08:00
yyerror("duplicate enum declaration for %s",
elem->name);
Addressed UNIX API issues reported by clang.
2015-06-19 04:31:10 +08:00
}
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
listpush(stack,(void*)(yyvsp[0].sym));
}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 1760 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
case 28:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 350 "ncgen.y" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
{
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
(yyvsp[-2].sym)->objectclass=NC_TYPE;
(yyvsp[-2].sym)->subclass=NC_ECONST;
(yyvsp[-2].sym)->typ.econst=(yyvsp[0].constant);
(yyval.sym)=(yyvsp[-2].sym);
}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 1771 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
case 29:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 359 "ncgen.y" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
{
Fixed the following Jira minor bugs: NCF-42: _Format attribute sometimes being ignored NCF-43: Fixed unsigned long long parsing. NCF-47: Make opendap code properly handle illegal names like "x.y" by supressing them NCF-49: check for uint type NCF-50: properly handle username:pwd embedded in urls.
2011-05-13 01:51:32 +08:00
vercheck(NC_OPAQUE);
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
addtogroup((yyvsp[0].sym)); /*sets prefix*/
(yyvsp[0].sym)->objectclass=NC_TYPE;
(yyvsp[0].sym)->subclass=NC_OPAQUE;
(yyvsp[0].sym)->typ.typecode=NC_OPAQUE;
(yyvsp[0].sym)->typ.size=int32_val;
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
(yyvsp[0].sym)->typ.alignment=ncaux_class_alignment(NC_OPAQUE);
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 1785 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
case 30:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 371 "ncgen.y" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
{
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
Symbol* basetype = (yyvsp[-4].sym);
Fixed the following Jira minor bugs: NCF-42: _Format attribute sometimes being ignored NCF-43: Fixed unsigned long long parsing. NCF-47: Make opendap code properly handle illegal names like "x.y" by supressing them NCF-49: check for uint type NCF-50: properly handle username:pwd embedded in urls.
2011-05-13 01:51:32 +08:00
vercheck(NC_VLEN);
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
addtogroup((yyvsp[0].sym)); /*sets prefix*/
(yyvsp[0].sym)->objectclass=NC_TYPE;
(yyvsp[0].sym)->subclass=NC_VLEN;
(yyvsp[0].sym)->typ.basetype=basetype;
(yyvsp[0].sym)->typ.typecode=NC_VLEN;
(yyvsp[0].sym)->typ.size=VLENSIZE;
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
(yyvsp[0].sym)->typ.alignment=ncaux_class_alignment(NC_VLEN);
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 1801 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
case 31:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 385 "ncgen.y" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
{
int i,j;
Fixed the following Jira minor bugs: NCF-42: _Format attribute sometimes being ignored NCF-43: Fixed unsigned long long parsing. NCF-47: Make opendap code properly handle illegal names like "x.y" by supressing them NCF-49: check for uint type NCF-50: properly handle username:pwd embedded in urls.
2011-05-13 01:51:32 +08:00
vercheck(NC_COMPOUND);
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
addtogroup((yyvsp[-3].sym));
moving to trunk subdir
2010-06-03 21:24:43 +08:00
/* check for duplicate field names*/
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
stackbase=(yyvsp[-1].mark);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
stacklen=listlength(stack);
for(i=stackbase;i<stacklen;i++) {
Symbol* elem1 = (Symbol*)listget(stack,i);
for(j=i+1;j<stacklen;j++) {
Symbol* elem2 = (Symbol*)listget(stack,j);
if(strcmp(elem1->name,elem2->name)==0) {
yyerror("duplicate field declaration for %s",elem1->name);
}
}
}
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
(yyvsp[-3].sym)->objectclass=NC_TYPE;
(yyvsp[-3].sym)->subclass=NC_COMPOUND;
(yyvsp[-3].sym)->typ.basetype=NULL;
(yyvsp[-3].sym)->typ.typecode=NC_COMPOUND;
(yyvsp[-3].sym)->subnodes = listnew();
moving to trunk subdir
2010-06-03 21:24:43 +08:00
/* Add in the fields*/
for(i=stackbase;i<stacklen;i++) {
Symbol* fsym = (Symbol*)listget(stack,i);
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
fsym->container = (yyvsp[-3].sym);
listpush((yyvsp[-3].sym)->subnodes,(void*)fsym);
Addressed UNIX API issues reported by clang.
2015-06-19 04:31:10 +08:00
}
moving to trunk subdir
2010-06-03 21:24:43 +08:00
listsetlength(stack,stackbase);/* remove stack nodes*/
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 1835 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
case 32:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 417 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.mark)=(yyvsp[-1].mark);}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 1841 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
case 33:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 418 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.mark)=(yyvsp[-2].mark);}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 1847 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
case 34:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 422 "ncgen.y" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
{
int i;
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
(yyval.mark)=(yyvsp[0].mark);
stackbase=(yyvsp[0].mark);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
stacklen=listlength(stack);
/* process each field in the fieldlist*/
for(i=stackbase;i<stacklen;i++) {
Symbol* f = (Symbol*)listget(stack,i);
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
f->typ.basetype = (yyvsp[-1].sym);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
}
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 1863 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
case 35:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 435 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{ (yyval.sym) = primsymbols[NC_CHAR]; }
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 1869 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
case 36:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 436 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{ (yyval.sym) = primsymbols[NC_BYTE]; }
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 1875 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
case 37:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 437 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{ (yyval.sym) = primsymbols[NC_SHORT]; }
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 1881 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
case 38:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 438 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{ (yyval.sym) = primsymbols[NC_INT]; }
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 1887 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
case 39:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 439 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{ (yyval.sym) = primsymbols[NC_FLOAT]; }
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 1893 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
case 40:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 440 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{ (yyval.sym) = primsymbols[NC_DOUBLE]; }
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 1899 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
case 41:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 441 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{ vercheck(NC_UBYTE); (yyval.sym) = primsymbols[NC_UBYTE]; }
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 1905 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
case 42:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 442 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{ vercheck(NC_USHORT); (yyval.sym) = primsymbols[NC_USHORT]; }
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 1911 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
case 43:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 443 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{ vercheck(NC_UINT); (yyval.sym) = primsymbols[NC_UINT]; }
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 1917 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
case 44:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 444 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{ vercheck(NC_INT64); (yyval.sym) = primsymbols[NC_INT64]; }
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 1923 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
case 45:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 445 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{ vercheck(NC_UINT64); (yyval.sym) = primsymbols[NC_UINT64]; }
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 1929 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 46:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 446 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{ vercheck(NC_STRING); (yyval.sym) = primsymbols[NC_STRING]; }
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 1935 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
case 48:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 450 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 1941 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 49:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 451 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 1947 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
case 52:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 458 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 1953 "ncgeny.c" /* yacc.c:1646 */
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
break;
case 53:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 458 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 1959 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 56:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 466 "ncgen.y" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
{
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
(yyvsp[-2].sym)->dim.declsize = (size_t)extractint((yyvsp[0].constant));
1. [NCF-276]/XXI-796914 Columbia server does not serve up proper opendap DDS replies. The Dataset {...} name changes depending on if the request has certain kinds of constraints. Code for a hack was not being used, so restore it. The fix is to effectively ignore differences in Dataset node names if the code is coming from columbia.edu. 2. [NCF-278] The ncgen code is improperly typing int64 integer constants as uint64. 3. [NCF-279] Empty string constants were not being properly filled when their target array is length 1 or more.
2013-11-18 05:26:14 +08:00
#ifdef GENDEBUG1
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
fprintf(stderr,"dimension: %s = %llu\n",(yyvsp[-2].sym)->name,(unsigned long long)(yyvsp[-2].sym)->dim.declsize);
Resolve Lynton's vlen problems (partially) re: jira NCF-145
2012-02-14 08:25:32 +08:00
#endif
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
reclaimconstant((yyvsp[0].constant));
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 1971 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 57:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 474 "ncgen.y" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
{
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
(yyvsp[-2].sym)->dim.declsize = NC_UNLIMITED;
(yyvsp[-2].sym)->dim.isunlimited = 1;
1. [NCF-276]/XXI-796914 Columbia server does not serve up proper opendap DDS replies. The Dataset {...} name changes depending on if the request has certain kinds of constraints. Code for a hack was not being used, so restore it. The fix is to effectively ignore differences in Dataset node names if the code is coming from columbia.edu. 2. [NCF-278] The ncgen code is improperly typing int64 integer constants as uint64. 3. [NCF-279] Empty string constants were not being properly filled when their target array is length 1 or more.
2013-11-18 05:26:14 +08:00
#ifdef GENDEBUG1
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
fprintf(stderr,"dimension: %s = UNLIMITED\n",(yyvsp[-2].sym)->name);
Resolve Lynton's vlen problems (partially) re: jira NCF-145
2012-02-14 08:25:32 +08:00
#endif
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 1983 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 58:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 484 "ncgen.y" /* yacc.c:1646 */
Addressed UNIX API issues reported by clang.
2015-06-19 04:31:10 +08:00
{
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
(yyvsp[0].sym)->objectclass=NC_DIM;
if(dupobjectcheck(NC_DIM,(yyvsp[0].sym)))
moving to trunk subdir
2010-06-03 21:24:43 +08:00
yyerror( "Duplicate dimension declaration for %s",
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
(yyvsp[0].sym)->name);
addtogroup((yyvsp[0].sym));
(yyval.sym)=(yyvsp[0].sym);
listpush(dimdefs,(void*)(yyvsp[0].sym));
}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 1997 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Add provenance info for netcdf-4 files. This consists of a persistent attribute named _NCProperties plus two computed attributes _IsNetcdf4 and _SuperblockVersion. See the 'Provenance Attributes' section of docs/attribute_conventions.md for details.
2016-05-04 11:17:06 +08:00
case 60:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 496 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2003 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 61:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 497 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2009 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Add provenance info for netcdf-4 files. This consists of a persistent attribute named _NCProperties plus two computed attributes _IsNetcdf4 and _SuperblockVersion. See the 'Provenance Attributes' section of docs/attribute_conventions.md for details.
2016-05-04 11:17:06 +08:00
case 64:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 504 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2015 "ncgeny.c" /* yacc.c:1646 */
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
break;
Add provenance info for netcdf-4 files. This consists of a persistent attribute named _NCProperties plus two computed attributes _IsNetcdf4 and _SuperblockVersion. See the 'Provenance Attributes' section of docs/attribute_conventions.md for details.
2016-05-04 11:17:06 +08:00
case 65:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 504 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2021 "ncgeny.c" /* yacc.c:1646 */
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
break;
case 66:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 507 "ncgen.y" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
{
int i;
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
stackbase=(yyvsp[0].mark);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
stacklen=listlength(stack);
/* process each variable in the varlist*/
for(i=stackbase;i<stacklen;i++) {
Symbol* sym = (Symbol*)listget(stack,i);
sym->objectclass = NC_VAR;
if(dupobjectcheck(NC_VAR,sym)) {
yyerror("Duplicate variable declaration for %s",
sym->name);
} else {
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
sym->typ.basetype = (yyvsp[-1].sym);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
addtogroup(sym);
update utilities: list,byte,hash,uri,log
2012-08-20 05:54:30 +08:00
listpush(vardefs,(void*)sym);
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
sym->var.special = ecalloc(sizeof(Specialdata));
if(sym->var.special == NULL)
derror("out of memory");
moving to trunk subdir
2010-06-03 21:24:43 +08:00
}
}
listsetlength(stack,stackbase);/* remove stack nodes*/
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2048 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 67:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 532 "ncgen.y" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
{(yyval.mark)=listlength(stack);
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
listpush(stack,(void*)(yyvsp[0].sym));
}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2056 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 68:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 536 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.mark)=(yyvsp[-2].mark); listpush(stack,(void*)(yyvsp[0].sym));}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2062 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 69:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 540 "ncgen.y" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
{
int i;
Dimset dimset;
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
Symbol* var = (yyvsp[-1].sym); /* for debugging */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
stacklen=listlength(stack);
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
stackbase=(yyvsp[0].mark);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
count = stacklen - stackbase;
if(count >= NC_MAX_VAR_DIMS) {
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
yyerror("%s has too many dimensions",(yyvsp[-1].sym)->name);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
count = NC_MAX_VAR_DIMS - 1;
stacklen = stackbase + count;
}
dimset.ndims = count;
/* extract the actual dimensions*/
if(dimset.ndims > 0) {
for(i=0;i<count;i++) {
Symbol* dsym = (Symbol*)listget(stack,stackbase+i);
dimset.dimsyms[i] = dsym;
}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
var->typ.dimset = dimset;
moving to trunk subdir
2010-06-03 21:24:43 +08:00
}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
var->typ.basetype = NULL; /* not yet known*/
var->objectclass=NC_VAR;
moving to trunk subdir
2010-06-03 21:24:43 +08:00
listsetlength(stack,stackbase);/* remove stack nodes*/
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
(yyval.sym) = var;
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2093 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 70:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 568 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.mark)=listlength(stack);}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2099 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 71:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 569 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.mark)=(yyvsp[-1].mark);}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2105 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 72:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 572 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.mark)=listlength(stack); listpush(stack,(void*)(yyvsp[0].sym));}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2111 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 73:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 574 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.mark)=(yyvsp[-2].mark); listpush(stack,(void*)(yyvsp[0].sym));}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2117 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 74:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 578 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{Symbol* dimsym = (yyvsp[0].sym);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
dimsym->objectclass = NC_DIM;
/* Find the actual dimension*/
dimsym = locate(dimsym);
if(dimsym == NULL) {
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
derror("Undefined or forward referenced dimension: %s",(yyvsp[0].sym)->name);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
YYABORT;
}
(yyval.sym)=dimsym;
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2132 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 75:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 592 "ncgen.y" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
{(yyval.mark)=listlength(stack);
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
listpush(stack,(void*)(yyvsp[0].sym));
}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2140 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 76:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 596 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.mark)=(yyvsp[-2].mark); listpush(stack,(void*)(yyvsp[0].sym));}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2146 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 77:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 601 "ncgen.y" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
{
int i;
Dimset dimset;
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
stackbase=(yyvsp[0].mark);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
stacklen=listlength(stack);
count = stacklen - stackbase;
if(count >= NC_MAX_VAR_DIMS) {
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
yyerror("%s has too many dimensions",(yyvsp[-1].sym)->name);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
count = NC_MAX_VAR_DIMS - 1;
stacklen = stackbase + count;
}
dimset.ndims = count;
if(count > 0) {
/* extract the actual dimensions*/
for(i=0;i<count;i++) {
Symbol* dsym = (Symbol*)listget(stack,stackbase+i);
dimset.dimsyms[i] = dsym;
}
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
(yyvsp[-1].sym)->typ.dimset = dimset;
moving to trunk subdir
2010-06-03 21:24:43 +08:00
}
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
(yyvsp[-1].sym)->typ.basetype = NULL; /* not yet known*/
(yyvsp[-1].sym)->objectclass=NC_TYPE;
(yyvsp[-1].sym)->subclass=NC_FIELD;
moving to trunk subdir
2010-06-03 21:24:43 +08:00
listsetlength(stack,stackbase);/* remove stack nodes*/
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
(yyval.sym) = (yyvsp[-1].sym);
}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2177 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 78:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 629 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.mark)=listlength(stack);}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2183 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 79:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 630 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.mark)=(yyvsp[-1].mark);}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2189 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 80:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 634 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.mark)=listlength(stack); listpush(stack,(void*)(yyvsp[0].sym));}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2195 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 81:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 636 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.mark)=(yyvsp[-2].mark); listpush(stack,(void*)(yyvsp[0].sym));}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2201 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 82:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 641 "ncgen.y" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
{ /* Anonymous integer dimension.
Can only occur in type definitions*/
char anon[32];
sprintf(anon,"const%u",uint32_val);
(yyval.sym) = install(anon);
(yyval.sym)->objectclass = NC_DIM;
(yyval.sym)->dim.isconstant = 1;
(yyval.sym)->dim.declsize = uint32_val;
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2215 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 83:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 651 "ncgen.y" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
{ /* Anonymous integer dimension.
Can only occur in type definitions*/
char anon[32];
if(int32_val <= 0) {
derror("field dimension must be positive");
YYABORT;
}
sprintf(anon,"const%d",int32_val);
(yyval.sym) = install(anon);
(yyval.sym)->objectclass = NC_DIM;
(yyval.sym)->dim.isconstant = 1;
(yyval.sym)->dim.declsize = int32_val;
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2233 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 84:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 671 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{Symbol* vsym = (yyvsp[0].sym);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
if(vsym->objectclass != NC_VAR) {
derror("Undefined or forward referenced variable: %s",vsym->name);
YYABORT;
}
(yyval.sym)=vsym;
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2245 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 85:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 682 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{Symbol* tsym = (yyvsp[0].sym);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
if(tsym->objectclass != NC_TYPE) {
derror("Undefined or forward referenced type: %s",tsym->name);
YYABORT;
}
(yyval.sym)=tsym;
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2257 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 86:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 693 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{Symbol* tvsym = (yyvsp[0].sym); Symbol* sym;
moving to trunk subdir
2010-06-03 21:24:43 +08:00
/* disambiguate*/
tvsym->objectclass = NC_VAR;
sym = locate(tvsym);
if(sym == NULL) {
tvsym->objectclass = NC_TYPE;
sym = locate(tvsym);
if(tvsym == NULL) {
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
derror("Undefined or forward referenced name: %s",(yyvsp[0].sym)->name);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
YYABORT;
} else tvsym = sym;
} else tvsym = sym;
if(tvsym == NULL) {
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
derror("Undefined name (line %d): %s",(yyvsp[0].sym)->lineno,(yyvsp[0].sym)->name);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
YYABORT;
}
(yyval.sym)=tvsym;
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2280 "ncgeny.c" /* yacc.c:1646 */
Add provenance info for netcdf-4 files. This consists of a persistent attribute named _NCProperties plus two computed attributes _IsNetcdf4 and _SuperblockVersion. See the 'Provenance Attributes' section of docs/attribute_conventions.md for details.
2016-05-04 11:17:06 +08:00
break;
case 87:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 711 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.sym)=(yyvsp[0].sym);}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2286 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
fixed: ncgen: nan bug made semicolons optional after type decls libncdap{3,4}: revamped the NC surrogate to better match with libsrc libdispatch: Added a new_nc function to the dispatch table; its purpose is to allow hierarchical use of NC compatible data structures. libsrc: cleaned up the NC structure by removing drno field general: removed --with-oc options
2010-11-10 06:53:03 +08:00
case 88:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 718 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2292 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
fixed: ncgen: nan bug made semicolons optional after type decls libncdap{3,4}: revamped the NC surrogate to better match with libsrc libdispatch: Added a new_nc function to the dispatch table; its purpose is to allow hierarchical use of NC compatible data structures. libsrc: cleaned up the NC structure by removing drno field general: removed --with-oc options
2010-11-10 06:53:03 +08:00
case 89:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 718 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2298 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
fixed: ncgen: nan bug made semicolons optional after type decls libncdap{3,4}: revamped the NC surrogate to better match with libsrc libdispatch: Added a new_nc function to the dispatch table; its purpose is to allow hierarchical use of NC compatible data structures. libsrc: cleaned up the NC structure by removing drno field general: removed --with-oc options
2010-11-10 06:53:03 +08:00
case 90:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 722 "ncgen.y" /* yacc.c:1646 */
{(yyval.sym) = makespecial(_NCPROPS_FLAG,NULL,NULL,(void*)(yyvsp[0].constant),ISCONST);}
#line 2304 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
fixed: ncgen: nan bug made semicolons optional after type decls libncdap{3,4}: revamped the NC surrogate to better match with libsrc libdispatch: Added a new_nc function to the dispatch table; its purpose is to allow hierarchical use of NC compatible data structures. libsrc: cleaned up the NC structure by removing drno field general: removed --with-oc options
2010-11-10 06:53:03 +08:00
case 91:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 724 "ncgen.y" /* yacc.c:1646 */
{(yyval.sym) = makespecial(_ISNETCDF4_FLAG,NULL,NULL,(void*)(yyvsp[0].constant),ISCONST);}
#line 2310 "ncgeny.c" /* yacc.c:1646 */
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
break;
case 92:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 726 "ncgen.y" /* yacc.c:1646 */
{(yyval.sym) = makespecial(_SUPERBLOCK_FLAG,NULL,NULL,(void*)(yyvsp[0].constant),ISCONST);}
#line 2316 "ncgeny.c" /* yacc.c:1646 */
Add provenance info for netcdf-4 files. This consists of a persistent attribute named _NCProperties plus two computed attributes _IsNetcdf4 and _SuperblockVersion. See the 'Provenance Attributes' section of docs/attribute_conventions.md for details.
2016-05-04 11:17:06 +08:00
break;
case 93:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 728 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{ (yyval.sym)=makeattribute((yyvsp[-2].sym),NULL,NULL,(yyvsp[0].datalist),ATTRGLOBAL);}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2322 "ncgeny.c" /* yacc.c:1646 */
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
break;
case 94:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 730 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{Symbol* tsym = (yyvsp[-5].sym); Symbol* vsym = (yyvsp[-4].sym); Symbol* asym = (yyvsp[-2].sym);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
if(vsym->objectclass == NC_VAR) {
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
(yyval.sym)=makeattribute(asym,vsym,tsym,(yyvsp[0].datalist),ATTRVAR);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
} else {
derror("Doubly typed attribute: %s",asym->name);
YYABORT;
}
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2335 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 95:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 739 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{Symbol* sym = (yyvsp[-4].sym); Symbol* asym = (yyvsp[-2].sym);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
if(sym->objectclass == NC_VAR) {
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
(yyval.sym)=makeattribute(asym,sym,NULL,(yyvsp[0].datalist),ATTRVAR);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
} else if(sym->objectclass == NC_TYPE) {
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
(yyval.sym)=makeattribute(asym,NULL,sym,(yyvsp[0].datalist),ATTRGLOBAL);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
} else {
derror("Attribute prefix not a variable or type: %s",asym->name);
YYABORT;
}
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2350 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 96:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 750 "ncgen.y" /* yacc.c:1646 */
{(yyval.sym) = makespecial(_FILLVALUE_FLAG,(yyvsp[-4].sym),NULL,(void*)(yyvsp[0].datalist),ISLIST);}
#line 2356 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 97:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 752 "ncgen.y" /* yacc.c:1646 */
{(yyval.sym) = makespecial(_FILLVALUE_FLAG,(yyvsp[-4].sym),(yyvsp[-5].sym),(void*)(yyvsp[0].datalist),ISLIST);}
#line 2362 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 98:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 754 "ncgen.y" /* yacc.c:1646 */
{(yyval.sym) = makespecial(_STORAGE_FLAG,(yyvsp[-4].sym),NULL,(void*)(yyvsp[0].constant),ISCONST);}
#line 2368 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 99:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 756 "ncgen.y" /* yacc.c:1646 */
{(yyval.sym) = makespecial(_CHUNKSIZES_FLAG,(yyvsp[-4].sym),NULL,(void*)(yyvsp[0].datalist),ISLIST);}
#line 2374 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 100:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 758 "ncgen.y" /* yacc.c:1646 */
{(yyval.sym) = makespecial(_FLETCHER32_FLAG,(yyvsp[-4].sym),NULL,(void*)(yyvsp[0].constant),ISCONST);}
#line 2380 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 101:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 760 "ncgen.y" /* yacc.c:1646 */
{(yyval.sym) = makespecial(_DEFLATE_FLAG,(yyvsp[-4].sym),NULL,(void*)(yyvsp[0].constant),ISCONST);}
#line 2386 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 102:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 762 "ncgen.y" /* yacc.c:1646 */
{(yyval.sym) = makespecial(_SHUFFLE_FLAG,(yyvsp[-4].sym),NULL,(void*)(yyvsp[0].constant),ISCONST);}
#line 2392 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 103:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 764 "ncgen.y" /* yacc.c:1646 */
{(yyval.sym) = makespecial(_ENDIAN_FLAG,(yyvsp[-4].sym),NULL,(void*)(yyvsp[0].constant),ISCONST);}
#line 2398 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 104:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 766 "ncgen.y" /* yacc.c:1646 */
{(yyval.sym) = makespecial(_FILTER_FLAG,(yyvsp[-4].sym),NULL,(void*)(yyvsp[0].constant),ISCONST);}
#line 2404 "ncgeny.c" /* yacc.c:1646 */
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 105:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 768 "ncgen.y" /* yacc.c:1646 */
{(yyval.sym) = makespecial(_NOFILL_FLAG,(yyvsp[-4].sym),NULL,(void*)(yyvsp[0].constant),ISCONST);}
#line 2410 "ncgeny.c" /* yacc.c:1646 */
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
break;
case 106:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 770 "ncgen.y" /* yacc.c:1646 */
{(yyval.sym) = makespecial(_FORMAT_FLAG,NULL,NULL,(void*)(yyvsp[0].constant),ISCONST);}
#line 2416 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
case 107:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 775 "ncgen.y" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
{
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
(yyval.sym)=(yyvsp[0].sym);
(yyvsp[0].sym)->ref.is_ref=1;
(yyvsp[0].sym)->is_prefixed=0;
setpathcurrent((yyvsp[0].sym));
}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2427 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
case 108:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 782 "ncgen.y" /* yacc.c:1646 */
Add provenance info for netcdf-4 files. This consists of a persistent attribute named _NCProperties plus two computed attributes _IsNetcdf4 and _SuperblockVersion. See the 'Provenance Attributes' section of docs/attribute_conventions.md for details.
2016-05-04 11:17:06 +08:00
{
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
(yyval.sym)=(yyvsp[0].sym);
(yyvsp[0].sym)->ref.is_ref=1;
(yyvsp[0].sym)->is_prefixed=1;
Add provenance info for netcdf-4 files. This consists of a persistent attribute named _NCProperties plus two computed attributes _IsNetcdf4 and _SuperblockVersion. See the 'Provenance Attributes' section of docs/attribute_conventions.md for details.
2016-05-04 11:17:06 +08:00
/* path is set in ncgen.l*/
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2438 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
case 110:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 791 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2444 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
case 111:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 792 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2450 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
case 114:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 800 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyvsp[-2].sym)->data = (yyvsp[0].datalist);}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2456 "ncgeny.c" /* yacc.c:1646 */
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
break;
case 115:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 803 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.datalist) = (yyvsp[0].datalist);}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2462 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 116:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 804 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.datalist) = (yyvsp[0].datalist);}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2468 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 117:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 808 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.datalist) = builddatalist(0);}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2474 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 118:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 812 "ncgen.y" /* yacc.c:1646 */
{(yyval.datalist) = const2list((yyvsp[0].constant));}
#line 2480 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 119:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 814 "ncgen.y" /* yacc.c:1646 */
{dlappend((yyvsp[-2].datalist),((yyvsp[0].constant))); (yyval.datalist)=(yyvsp[-2].datalist); }
#line 2486 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 120:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 818 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.constant)=(yyvsp[0].constant);}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2492 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 121:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 819 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.constant)=builddatasublist((yyvsp[-1].datalist));}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2498 "ncgeny.c" /* yacc.c:1646 */
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
break;
case 122:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 823 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.constant)=(yyvsp[0].constant);}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2504 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
case 123:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 824 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.constant)=makeconstdata(NC_OPAQUE);}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2510 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
case 124:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 825 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.constant)=makeconstdata(NC_FILLVALUE);}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2516 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
case 125:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 826 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.constant)=makeconstdata(NC_NIL);}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2522 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
case 126:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 827 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.constant)=(yyvsp[0].constant);}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2528 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
case 128:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 832 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.constant) = makeenumconstref((yyvsp[0].sym));}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2534 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
case 129:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 836 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.constant)=evaluate((yyvsp[-3].sym),(yyvsp[-1].datalist));}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2540 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
case 130:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 841 "ncgen.y" /* yacc.c:1646 */
{(yyval.datalist) = const2list((yyvsp[0].constant));}
#line 2546 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
case 131:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 843 "ncgen.y" /* yacc.c:1646 */
{dlappend((yyvsp[-2].datalist),((yyvsp[0].constant))); (yyval.datalist)=(yyvsp[-2].datalist);}
#line 2552 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
case 132:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 847 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.constant)=makeconstdata(NC_CHAR);}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2558 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
case 133:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 848 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.constant)=makeconstdata(NC_BYTE);}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2564 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
case 134:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 849 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.constant)=makeconstdata(NC_SHORT);}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2570 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
case 135:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 850 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.constant)=makeconstdata(NC_INT);}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2576 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
case 136:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 851 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.constant)=makeconstdata(NC_INT64);}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2582 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
case 137:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 852 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.constant)=makeconstdata(NC_UBYTE);}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2588 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
case 138:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 853 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.constant)=makeconstdata(NC_USHORT);}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2594 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
case 139:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 854 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.constant)=makeconstdata(NC_UINT);}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2600 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
case 140:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 855 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.constant)=makeconstdata(NC_UINT64);}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2606 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
case 141:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 856 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.constant)=makeconstdata(NC_FLOAT);}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2612 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
case 142:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 857 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.constant)=makeconstdata(NC_DOUBLE);}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2618 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
case 143:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 858 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.constant)=makeconstdata(NC_STRING);}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2624 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 144:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 862 "ncgen.y" /* yacc.c:1646 */
{(yyval.datalist) = const2list((yyvsp[0].constant));}
#line 2630 "ncgeny.c" /* yacc.c:1646 */
fix NCF-120
2011-09-16 00:57:16 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 145:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 863 "ncgen.y" /* yacc.c:1646 */
{(yyval.datalist)=(yyvsp[-2].datalist); dlappend((yyvsp[-2].datalist),((yyvsp[0].constant)));}
#line 2636 "ncgeny.c" /* yacc.c:1646 */
fix NCF-120
2011-09-16 00:57:16 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 146:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 868 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.constant)=makeconstdata(NC_INT);}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2642 "ncgeny.c" /* yacc.c:1646 */
fix NCF-120
2011-09-16 00:57:16 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 147:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 870 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.constant)=makeconstdata(NC_UINT);}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2648 "ncgeny.c" /* yacc.c:1646 */
fix NCF-120
2011-09-16 00:57:16 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 148:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 872 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.constant)=makeconstdata(NC_INT64);}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2654 "ncgeny.c" /* yacc.c:1646 */
fix NCF-120
2011-09-16 00:57:16 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 149:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 874 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.constant)=makeconstdata(NC_UINT64);}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2660 "ncgeny.c" /* yacc.c:1646 */
typo in ncgen.y
2012-01-16 09:29:19 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 150:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 878 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.constant)=makeconstdata(NC_STRING);}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2666 "ncgeny.c" /* yacc.c:1646 */
Added code to support NIL values for strings in ncgen. Needs test cases.
2013-07-11 04:00:48 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 151:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 882 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.constant)=(yyvsp[0].constant);}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2672 "ncgeny.c" /* yacc.c:1646 */
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 152:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 883 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.constant)=(yyvsp[0].constant);}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2678 "ncgeny.c" /* yacc.c:1646 */
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
break;
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
case 153:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 889 "ncgen.y" /* yacc.c:1646 */
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{(yyval.sym)=(yyvsp[0].sym);}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2684 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 2688 "ncgeny.c" /* yacc.c:1646 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
default: break;
}
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
/* User semantic actions sometimes alter yychar, and that requires
that yytoken be updated with the new translation. We take the
approach of translating immediately before every use of yytoken.
One alternative is translating here after every semantic action,
but that translation would be missed if the semantic action invokes
YYABORT, YYACCEPT, or YYERROR immediately after altering yychar or
if it invokes YYBACKUP. In the case of YYABORT or YYACCEPT, an
incorrect destructor might then be invoked immediately. In the
case of YYERROR or YYBACKUP, subsequent parser actions might lead
to an incorrect destructor call or verbose syntax error message
before the lookahead is translated. */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
YY_SYMBOL_PRINT ("-> $$ =", yyr1[yyn], &yyval, &yyloc);
YYPOPSTACK (yylen);
yylen = 0;
YY_STACK_PRINT (yyss, yyssp);
*++yyvsp = yyval;
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
/* Now 'shift' the result of the reduction. Determine what state
moving to trunk subdir
2010-06-03 21:24:43 +08:00
that goes to, based on the state we popped back to and the rule
number reduced by. */
yyn = yyr1[yyn];
yystate = yypgoto[yyn - YYNTOKENS] + *yyssp;
if (0 <= yystate && yystate <= YYLAST && yycheck[yystate] == *yyssp)
yystate = yytable[yystate];
else
yystate = yydefgoto[yyn - YYNTOKENS];
goto yynewstate;
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
/*--------------------------------------.
| yyerrlab -- here on detecting error. |
`--------------------------------------*/
moving to trunk subdir
2010-06-03 21:24:43 +08:00
yyerrlab:
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
/* Make sure we have latest lookahead translation. See comments at
user semantic actions for why this is necessary. */
yytoken = yychar == YYEMPTY ? YYEMPTY : YYTRANSLATE (yychar);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
/* If not already recovering from an error, report this error. */
if (!yyerrstatus)
{
++yynerrs;
#if ! YYERROR_VERBOSE
yyerror (YY_("syntax error"));
#else
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
# define YYSYNTAX_ERROR yysyntax_error (&yymsg_alloc, &yymsg, \
yyssp, yytoken)
moving to trunk subdir
2010-06-03 21:24:43 +08:00
{
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
char const *yymsgp = YY_("syntax error");
int yysyntax_error_status;
yysyntax_error_status = YYSYNTAX_ERROR;
if (yysyntax_error_status == 0)
yymsgp = yymsg;
else if (yysyntax_error_status == 1)
{
if (yymsg != yymsgbuf)
YYSTACK_FREE (yymsg);
yymsg = (char *) YYSTACK_ALLOC (yymsg_alloc);
if (!yymsg)
{
yymsg = yymsgbuf;
yymsg_alloc = sizeof yymsgbuf;
yysyntax_error_status = 2;
}
else
{
yysyntax_error_status = YYSYNTAX_ERROR;
yymsgp = yymsg;
}
}
yyerror (yymsgp);
if (yysyntax_error_status == 2)
goto yyexhaustedlab;
moving to trunk subdir
2010-06-03 21:24:43 +08:00
}
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
# undef YYSYNTAX_ERROR
moving to trunk subdir
2010-06-03 21:24:43 +08:00
#endif
}
if (yyerrstatus == 3)
{
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
/* If just tried and failed to reuse lookahead token after an
error, discard it. */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
if (yychar <= YYEOF)
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{
/* Return failure if at end of input. */
if (yychar == YYEOF)
YYABORT;
}
moving to trunk subdir
2010-06-03 21:24:43 +08:00
else
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
{
yydestruct ("Error: discarding",
yytoken, &yylval);
yychar = YYEMPTY;
}
moving to trunk subdir
2010-06-03 21:24:43 +08:00
}
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
/* Else will try to reuse lookahead token after shifting the error
moving to trunk subdir
2010-06-03 21:24:43 +08:00
token. */
goto yyerrlab1;
/*---------------------------------------------------.
| yyerrorlab -- error raised explicitly by YYERROR. |
`---------------------------------------------------*/
yyerrorlab:
/* Pacify compilers like GCC when the user code never invokes
YYERROR and the label yyerrorlab therefore never appears in user
code. */
if (/*CONSTCOND*/ 0)
goto yyerrorlab;
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
/* Do not reclaim the symbols of the rule whose action triggered
moving to trunk subdir
2010-06-03 21:24:43 +08:00
this YYERROR. */
YYPOPSTACK (yylen);
yylen = 0;
YY_STACK_PRINT (yyss, yyssp);
yystate = *yyssp;
goto yyerrlab1;
/*-------------------------------------------------------------.
| yyerrlab1 -- common code for both syntax error and YYERROR. |
`-------------------------------------------------------------*/
yyerrlab1:
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
yyerrstatus = 3; /* Each real token shifted decrements this. */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
for (;;)
{
yyn = yypact[yystate];
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
if (!yypact_value_is_default (yyn))
{
yyn += YYTERROR;
if (0 <= yyn && yyn <= YYLAST && yycheck[yyn] == YYTERROR)
{
yyn = yytable[yyn];
if (0 < yyn)
break;
}
}
moving to trunk subdir
2010-06-03 21:24:43 +08:00
/* Pop the current state because it cannot handle the error token. */
if (yyssp == yyss)
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
YYABORT;
moving to trunk subdir
2010-06-03 21:24:43 +08:00
yydestruct ("Error: popping",
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
yystos[yystate], yyvsp);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
YYPOPSTACK (1);
yystate = *yyssp;
YY_STACK_PRINT (yyss, yyssp);
}
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
YY_IGNORE_MAYBE_UNINITIALIZED_BEGIN
moving to trunk subdir
2010-06-03 21:24:43 +08:00
*++yyvsp = yylval;
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
YY_IGNORE_MAYBE_UNINITIALIZED_END
moving to trunk subdir
2010-06-03 21:24:43 +08:00
/* Shift the error token. */
YY_SYMBOL_PRINT ("Shifting", yystos[yyn], yyvsp, yylsp);
yystate = yyn;
goto yynewstate;
/*-------------------------------------.
| yyacceptlab -- YYACCEPT comes here. |
`-------------------------------------*/
yyacceptlab:
yyresult = 0;
goto yyreturn;
/*-----------------------------------.
| yyabortlab -- YYABORT comes here. |
`-----------------------------------*/
yyabortlab:
yyresult = 1;
goto yyreturn;
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
#if !defined yyoverflow || YYERROR_VERBOSE
moving to trunk subdir
2010-06-03 21:24:43 +08:00
/*-------------------------------------------------.
| yyexhaustedlab -- memory exhaustion comes here. |
`-------------------------------------------------*/
yyexhaustedlab:
yyerror (YY_("memory exhausted"));
yyresult = 2;
/* Fall through. */
#endif
yyreturn:
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
if (yychar != YYEMPTY)
{
/* Make sure we have latest lookahead translation. See comments at
user semantic actions for why this is necessary. */
yytoken = YYTRANSLATE (yychar);
yydestruct ("Cleanup: discarding lookahead",
yytoken, &yylval);
}
/* Do not reclaim the symbols of the rule whose action triggered
moving to trunk subdir
2010-06-03 21:24:43 +08:00
this YYABORT or YYACCEPT. */
YYPOPSTACK (yylen);
YY_STACK_PRINT (yyss, yyssp);
while (yyssp != yyss)
{
yydestruct ("Cleanup: popping",
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
yystos[*yyssp], yyvsp);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
YYPOPSTACK (1);
}
#ifndef yyoverflow
if (yyss != yyssa)
YYSTACK_FREE (yyss);
#endif
#if YYERROR_VERBOSE
if (yymsg != yymsgbuf)
YYSTACK_FREE (yymsg);
#endif
1. Keep up to date by merging master 2. Fixed plugin building (nc_test4/hdf5plugins) to be done properly by cmake and automake. 4. Duplicated part of the nc_test4 filter test code in examples/C An incomplete and untested set of hooks exist for OS-X in nc_test4/findplugins.in. They need testing.
2018-01-17 02:00:09 +08:00
return yyresult;
moving to trunk subdir
2010-06-03 21:24:43 +08:00
}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
#line 892 "ncgen.y" /* yacc.c:1906 */
moving to trunk subdir
2010-06-03 21:24:43 +08:00
#ifndef NO_STDARG
static void
yyerror(const char *fmt, ...)
#else
static void
yyerror(fmt,va_alist) const char* fmt; va_dcl
#endif
{
va_list argv;
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
va_start(argv,fmt);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
(void)fprintf(stderr,"%s: %s line %d: ", progname, cdlname, lineno);
vderror(fmt,argv);
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
va_end(argv);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
}
/* undefine yywrap macro, in case we are using bison instead of yacc */
#ifdef yywrap
#undef yywrap
#endif
static int
ncgwrap(void) /* returns 1 on EOF if no more input */
{
return 1;
}
/* get lexical input routine generated by lex */
ckp
2015-11-20 04:44:07 +08:00
#include "ncgenl.c"
moving to trunk subdir
2010-06-03 21:24:43 +08:00
/* Really should init our data within this file */
void
parse_init(void)
{
int i;
opaqueid = 0;
arrayuid = 0;
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
symlist = listnew();
moving to trunk subdir
2010-06-03 21:24:43 +08:00
stack = listnew();
groupstack = listnew();
consttype = NC_NAT;
grpdefs = listnew();
dimdefs = listnew();
attdefs = listnew();
gattdefs = listnew();
xattdefs = listnew();
typdefs = listnew();
vardefs = listnew();
condefs = listnew();
tmp = listnew();
/* Create the primitive types */
for(i=NC_NAT+1;i<=NC_STRING;i++) {
primsymbols[i] = makeprimitivetype(i);
}
lex_init();
}
static Symbol*
makeprimitivetype(nc_type nctype)
{
Symbol* sym = install(primtypenames[nctype]);
sym->objectclass=NC_TYPE;
sym->subclass=NC_PRIM;
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
sym->nc_id = nctype;
moving to trunk subdir
2010-06-03 21:24:43 +08:00
sym->typ.typecode = nctype;
sym->typ.size = ncsize(nctype);
sym->typ.nelems = 1;
Fix errors when building on big-endian machine re: issue https://github.com/Unidata/netcdf-c/issues/1278 re: issue https://github.com/Unidata/netcdf-c/issues/876 re: issue https://github.com/Unidata/netcdf-c/issues/806 * Major change to the handling of 8-byte parameters for nc_def_var_filter. The old code was not well thought out. * The new algorithm is documented in docs/filters.md. * Added new utility file plugins/H5Zutil.c to support * Modified plugins/H5Zmisc.c to use new algorithm the new algorithm. * Renamed include/ncfilter.h to include/netcdf_filter.h and made it an installed header so clients can access the new algorithm utility. * Fixed nc_test4/tst_filterparser.c and nc_test4/test_filter_misc.c to use the new algorithm * libdap4/ fixes: * d4swap.c has an error in the endian pre-processing such that record counts were not being swapped correctly. * d4data.c had an error in that checksums were being computed after endian swapping rather than before. * ocinitialize() was never being called, so xxdr bigendian handling was never set correctly. * Required adding debug statements to occompile * Found and fixed memory leak in ncdump.c Not tested: * HDF4 * Pnetcdf * parallel HDF5
2019-02-01 12:13:06 +08:00
sym->typ.alignment = ncaux_class_alignment(nctype);
fix discovered bug in opaque data handling
2012-05-05 03:22:30 +08:00
/* Make the basetype circular so we can always ask for it */
sym->typ.basetype = sym;
moving to trunk subdir
2010-06-03 21:24:43 +08:00
sym->prefix = listnew();
return sym;
}
/* Symbol table operations for ncgen tool */
/* install sname in symbol table even if it is already there */
Symbol*
install(const char *sname)
{
Symbol* sp;
Cleanup ncgen memory management
2017-10-31 05:52:08 +08:00
sp = (Symbol*) ecalloc (sizeof (struct Symbol));
moving to trunk subdir
2010-06-03 21:24:43 +08:00
sp->name = nulldup(sname);
sp->lineno = lineno;
sp->location = currentgroup();
sp->container = currentgroup();
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
listpush(symlist,sp);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
return sp;
}
static Symbol*
currentgroup(void)
{
if(listlength(groupstack) == 0) return rootgroup;
return (Symbol*)listtop(groupstack);
}
static Symbol*
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
createrootgroup(const char* dataset)
moving to trunk subdir
2010-06-03 21:24:43 +08:00
{
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
Symbol* gsym = install(dataset);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
gsym->objectclass = NC_GRP;
gsym->container = NULL;
gsym->subnodes = listnew();
gsym->grp.is_root = 1;
gsym->prefix = listnew();
update utilities: list,byte,hash,uri,log
2012-08-20 05:54:30 +08:00
listpush(grpdefs,(void*)gsym);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
rootgroup = gsym;
return gsym;
}
static Symbol*
creategroup(Symbol * gsym)
{
/* See if this group already exists in currentgroup */
gsym->objectclass = NC_GRP;
if(dupobjectcheck(NC_GRP,gsym)) {
derror("Duplicate group name in same scope: %s",gsym->name);
return NULL;
}
addtogroup(gsym);
gsym->subnodes = listnew();
update utilities: list,byte,hash,uri,log
2012-08-20 05:54:30 +08:00
listpush(groupstack,(void*)gsym);
listpush(grpdefs,(void*)gsym);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
return gsym;
}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
static NCConstant*
moving to trunk subdir
2010-06-03 21:24:43 +08:00
makeconstdata(nc_type nctype)
{
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
NCConstant* con = nullconst();
moving to trunk subdir
2010-06-03 21:24:43 +08:00
consttype = nctype;
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
con->nctype = nctype;
con->lineno = lineno;
con->filled = 0;
moving to trunk subdir
2010-06-03 21:24:43 +08:00
switch (nctype) {
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
case NC_CHAR: con->value.charv = char_val; break;
case NC_BYTE: con->value.int8v = byte_val; break;
case NC_SHORT: con->value.int16v = int16_val; break;
case NC_INT: con->value.int32v = int32_val; break;
fixed: ncgen: nan bug made semicolons optional after type decls libncdap{3,4}: revamped the NC surrogate to better match with libsrc libdispatch: Added a new_nc function to the dispatch table; its purpose is to allow hierarchical use of NC compatible data structures. libsrc: cleaned up the NC structure by removing drno field general: removed --with-oc options
2010-11-10 06:53:03 +08:00
case NC_FLOAT:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
con->value.floatv = float_val;
fixed: ncgen: nan bug made semicolons optional after type decls libncdap{3,4}: revamped the NC surrogate to better match with libsrc libdispatch: Added a new_nc function to the dispatch table; its purpose is to allow hierarchical use of NC compatible data structures. libsrc: cleaned up the NC structure by removing drno field general: removed --with-oc options
2010-11-10 06:53:03 +08:00
break;
case NC_DOUBLE:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
con->value.doublev = double_val;
fixed: ncgen: nan bug made semicolons optional after type decls libncdap{3,4}: revamped the NC surrogate to better match with libsrc libdispatch: Added a new_nc function to the dispatch table; its purpose is to allow hierarchical use of NC compatible data structures. libsrc: cleaned up the NC structure by removing drno field general: removed --with-oc options
2010-11-10 06:53:03 +08:00
break;
moving to trunk subdir
2010-06-03 21:24:43 +08:00
case NC_STRING: { /* convert to a set of chars*/
close Jira NCF-154
2012-03-08 07:38:51 +08:00
size_t len;
Resolve Lynton's vlen problems (partially) re: jira NCF-145
2012-02-14 08:25:32 +08:00
len = bbLength(lextext);
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
con->value.stringv.len = len;
con->value.stringv.stringv = bbExtract(lextext);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
}
break;
/* Allow these constants even in netcdf-3 */
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
case NC_UBYTE: con->value.uint8v = ubyte_val; break;
case NC_USHORT: con->value.uint16v = uint16_val; break;
case NC_UINT: con->value.uint32v = uint32_val; break;
case NC_INT64: con->value.int64v = int64_val; break;
case NC_UINT64: con->value.uint64v = uint64_val; break;
moving to trunk subdir
2010-06-03 21:24:43 +08:00
#ifdef USE_NETCDF4
case NC_OPAQUE: {
char* s;
fix bug in opaque parsing
2012-05-06 06:31:24 +08:00
int len;
Resolve Lynton's vlen problems (partially) re: jira NCF-145
2012-02-14 08:25:32 +08:00
len = bbLength(lextext);
Cleanup ncgen memory management
2017-10-31 05:52:08 +08:00
s = (char*)ecalloc(len+1);
Resolve Lynton's vlen problems (partially) re: jira NCF-145
2012-02-14 08:25:32 +08:00
strncpy(s,bbContents(lextext),len);
fix bug in opaque parsing
2012-05-06 06:31:24 +08:00
s[len] = '\0';
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
con->value.opaquev.stringv = s;
con->value.opaquev.len = len;
moving to trunk subdir
2010-06-03 21:24:43 +08:00
} break;
Added code to support NIL values for strings in ncgen. Needs test cases.
2013-07-11 04:00:48 +08:00
case NC_NIL:
break; /* no associated value*/
moving to trunk subdir
2010-06-03 21:24:43 +08:00
#endif
Cleanup some ncgen memory problems
2017-11-01 04:03:57 +08:00
case NC_FILLVALUE:
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break; /* no associated value*/
Added code to support NIL values for strings in ncgen. Needs test cases.
2013-07-11 04:00:48 +08:00
moving to trunk subdir
2010-06-03 21:24:43 +08:00
default:
yyerror("Data constant: unexpected NC type: %s",
nctypename(nctype));
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
con->value.stringv.stringv = NULL;
con->value.stringv.len = 0;
moving to trunk subdir
2010-06-03 21:24:43 +08:00
}
return con;
}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
static NCConstant*
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
makeenumconstref(Symbol* refsym)
moving to trunk subdir
2010-06-03 21:24:43 +08:00
{
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
NCConstant* con = nullconst();
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
Resolve Lynton's vlen problems (partially) re: jira NCF-145
2012-02-14 08:25:32 +08:00
markcdf4("Enum type");
moving to trunk subdir
2010-06-03 21:24:43 +08:00
consttype = NC_ENUM;
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
con->nctype = NC_ECONST;
con->lineno = lineno;
con->filled = 0;
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
refsym->objectclass = NC_TYPE;
refsym->subclass = NC_ECONST;
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
con->value.enumv = refsym;
moving to trunk subdir
2010-06-03 21:24:43 +08:00
return con;
}
static void
addtogroup(Symbol* sym)
{
Symbol* grp = currentgroup();
sym->container = grp;
update utilities: list,byte,hash,uri,log
2012-08-20 05:54:30 +08:00
listpush(grp->subnodes,(void*)sym);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
setpathcurrent(sym);
}
/* Check for duplicate name of given type within current group*/
static int
dupobjectcheck(nc_class objectclass, Symbol* pattern)
{
int i;
Symbol* grp;
if(pattern == NULL) return 0;
grp = pattern->container;
if(grp == NULL || grp->subnodes == NULL) return 0;
for(i=0;i<listlength(grp->subnodes);i++) {
Symbol* sym = (Symbol*)listget(grp->subnodes,i);
[NCF-265] Ncgen is unable to resolve ambiguous references to an enum constant when two different enums have same econstant name. Solved by allowing more specific forms for econstant references. 1. /.../enumname.enumconstname 2. enumname.enumconstname 3. enumconstname Case 1 is resolved by using the econstant in the specific enum definition. If none is found, an error is reported. Case 2 is resolved by 1. finding an enclosing group with an enum definition with the specified name and containing the specified econstant. If there are more than one, then an error is reported 2. finding all enum definitions in the dataset that have the specified enum name and contain the specified econstant. If more than one is found, then an error is reported. If the above two methods fail, then report an error. Case 3 is similar to case 2, but all enums, irrespective of name are used if they contains the specified enum constant. The ref_tst_econst.cdl test in ncdump is causing ncdump to fail. So there may be yet some problem.
2013-09-21 10:31:21 +08:00
if(!sym->ref.is_ref && sym->objectclass == objectclass
moving to trunk subdir
2010-06-03 21:24:43 +08:00
&& strcmp(sym->name,pattern->name)==0) return 1;
}
return 0;
}
static void
setpathcurrent(Symbol* sym)
{
sym->is_prefixed = 0;
sym->prefix = prefixdup(groupstack);
}
/* Convert an nc_type code to the corresponding Symbol*/
Symbol*
basetypefor(nc_type nctype)
{
return primsymbols[nctype];
}
static int
Refactored 'Constant' to 'NCConstant' in ncgen/ to avoid reserved word collision on Windows. Added tst_ncgen4_classic.sh to CMake-based builds.
2013-07-17 04:22:48 +08:00
truefalse(NCConstant* con, int tag)
moving to trunk subdir
2010-06-03 21:24:43 +08:00
{
if(con->nctype == NC_STRING) {
char* sdata = con->value.stringv.stringv;
if(strncmp(sdata,"false",NC_MAX_NAME) == 0
|| strncmp(sdata,"0",NC_MAX_NAME) == 0)
return 0;
else if(strncmp(sdata,"true",NC_MAX_NAME) == 0
|| strncmp(sdata,"1",NC_MAX_NAME) == 0)
return 1;
else goto fail;
} else if(con->value.int32v < 0 || con->value.int32v > 1)
goto fail;
return con->value.int32v;
fail:
derror("%s: illegal value",specialname(tag));
return 0;
}
/* Since this may be affected by the _Format attribute, which
may come last, capture all the special info and sort it out
in semantics.
*/
static Symbol*
makespecial(int tag, Symbol* vsym, Symbol* tsym, void* data, int isconst)
{
Symbol* attr = NULL;
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
Datalist* list = NULL;
NCConstant* con = NULL;
NCConstant* tmp = NULL;
moving to trunk subdir
2010-06-03 21:24:43 +08:00
int tf = 0;
char* sdata = NULL;
int idata = -1;
Addressed some instances of Coverity issue 711927, uninitialized scalar variable. Modified 'makeparser' target in CMake build system.
2013-08-15 00:12:49 +08:00
Add provenance info for netcdf-4 files. This consists of a persistent attribute named _NCProperties plus two computed attributes _IsNetcdf4 and _SuperblockVersion. See the 'Provenance Attributes' section of docs/attribute_conventions.md for details.
2016-05-04 11:17:06 +08:00
if((GLOBAL_SPECIAL & tag) != 0) {
1. Any test that references nctestserver/NC_findtestserver should be under ENABLE_DAP_REMOTE_TESTS. Fixed to make sure that this is so. Also attempted to fix ncdap_test/CMakeLists.txt, but probably got it wrong. HT to Nico Schlomer. 2. Attempted to reduce the number of conversion errors when -Wconversion is set. Fixed oc2, but rest of netcdf remains to be done. HT to Nico Schlomer. 3. When doing #2, I discovered an error in ncgen.y that has remained hidden. This required some other test case fixes.
2014-03-09 11:41:30 +08:00
if(vsym != NULL) {
derror("_Format: must be global attribute");
vsym = NULL;
}
} else {
if(vsym == NULL) {
derror("%s: must have non-NULL vsym", specialname(tag));
return NULL;
}
}
Addressed some instances of Coverity issue 711927, uninitialized scalar variable. Modified 'makeparser' target in CMake build system.
2013-08-15 00:12:49 +08:00
1. Any test that references nctestserver/NC_findtestserver should be under ENABLE_DAP_REMOTE_TESTS. Fixed to make sure that this is so. Also attempted to fix ncdap_test/CMakeLists.txt, but probably got it wrong. HT to Nico Schlomer. 2. Attempted to reduce the number of conversion errors when -Wconversion is set. Fixed oc2, but rest of netcdf remains to be done. HT to Nico Schlomer. 3. When doing #2, I discovered an error in ncgen.y that has remained hidden. This required some other test case fixes.
2014-03-09 11:41:30 +08:00
if(tag != _FILLVALUE_FLAG && tag != _FORMAT_FLAG)
/*Main.*/specials_flag++;
Resolve Lynton's vlen problems (partially) re: jira NCF-145
2012-02-14 08:25:32 +08:00
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
if(isconst)
Refactored 'Constant' to 'NCConstant' in ncgen/ to avoid reserved word collision on Windows. Added tst_ncgen4_classic.sh to CMake-based builds.
2013-07-17 04:22:48 +08:00
con = (NCConstant*)data;
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
else
moving to trunk subdir
2010-06-03 21:24:43 +08:00
list = (Datalist*)data;
switch (tag) {
case _FLETCHER32_FLAG:
case _SHUFFLE_FLAG:
Add provenance info for netcdf-4 files. This consists of a persistent attribute named _NCProperties plus two computed attributes _IsNetcdf4 and _SuperblockVersion. See the 'Provenance Attributes' section of docs/attribute_conventions.md for details.
2016-05-04 11:17:06 +08:00
case _ISNETCDF4_FLAG:
moving to trunk subdir
2010-06-03 21:24:43 +08:00
case _NOFILL_FLAG:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
tmp = nullconst();
tmp->nctype = (con->nctype == NC_STRING?NC_STRING:NC_INT);
convert1(con,tmp);
tf = truefalse(tmp,tag);
reclaimconstant(tmp);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
case _FORMAT_FLAG:
case _STORAGE_FLAG:
Add provenance info for netcdf-4 files. This consists of a persistent attribute named _NCProperties plus two computed attributes _IsNetcdf4 and _SuperblockVersion. See the 'Provenance Attributes' section of docs/attribute_conventions.md for details.
2016-05-04 11:17:06 +08:00
case _NCPROPS_FLAG:
moving to trunk subdir
2010-06-03 21:24:43 +08:00
case _ENDIAN_FLAG:
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
case _FILTER_FLAG:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
tmp = nullconst();
tmp->nctype = NC_STRING;
convert1(con,tmp);
if(tmp->nctype == NC_STRING) {
sdata = tmp->value.stringv.stringv;
tmp->value.stringv.stringv = NULL;
tmp->value.stringv.len = 0;
} else
moving to trunk subdir
2010-06-03 21:24:43 +08:00
derror("%s: illegal value",specialname(tag));
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
reclaimconstant(tmp);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
Add provenance info for netcdf-4 files. This consists of a persistent attribute named _NCProperties plus two computed attributes _IsNetcdf4 and _SuperblockVersion. See the 'Provenance Attributes' section of docs/attribute_conventions.md for details.
2016-05-04 11:17:06 +08:00
case _SUPERBLOCK_FLAG:
moving to trunk subdir
2010-06-03 21:24:43 +08:00
case _DEFLATE_FLAG:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
tmp = nullconst();
tmp->nctype = NC_INT;
convert1(con,tmp);
if(tmp->nctype == NC_INT)
idata = tmp->value.int32v;
moving to trunk subdir
2010-06-03 21:24:43 +08:00
else
derror("%s: illegal value",specialname(tag));
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
reclaimconstant(tmp);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
case _CHUNKSIZES_FLAG:
case _FILLVALUE_FLAG:
/* Handle below */
break;
default: PANIC1("unexpected special tag: %d",tag);
}
Addressed UNIX API issues reported by clang.
2015-06-19 04:31:10 +08:00
moving to trunk subdir
2010-06-03 21:24:43 +08:00
if(tag == _FORMAT_FLAG) {
1. Any test that references nctestserver/NC_findtestserver should be under ENABLE_DAP_REMOTE_TESTS. Fixed to make sure that this is so. Also attempted to fix ncdap_test/CMakeLists.txt, but probably got it wrong. HT to Nico Schlomer. 2. Attempted to reduce the number of conversion errors when -Wconversion is set. Fixed oc2, but rest of netcdf remains to be done. HT to Nico Schlomer. 3. When doing #2, I discovered an error in ncgen.y that has remained hidden. This required some other test case fixes.
2014-03-09 11:41:30 +08:00
/* Watch out: this is a global attribute */
Fixed the following Jira minor bugs: NCF-42: _Format attribute sometimes being ignored NCF-43: Fixed unsigned long long parsing. NCF-47: Make opendap code properly handle illegal names like "x.y" by supressing them NCF-49: check for uint type NCF-50: properly handle username:pwd embedded in urls.
2011-05-13 01:51:32 +08:00
struct Kvalues* kvalue;
1. Any test that references nctestserver/NC_findtestserver should be under ENABLE_DAP_REMOTE_TESTS. Fixed to make sure that this is so. Also attempted to fix ncdap_test/CMakeLists.txt, but probably got it wrong. HT to Nico Schlomer. 2. Attempted to reduce the number of conversion errors when -Wconversion is set. Fixed oc2, but rest of netcdf remains to be done. HT to Nico Schlomer. 3. When doing #2, I discovered an error in ncgen.y that has remained hidden. This required some other test case fixes.
2014-03-09 11:41:30 +08:00
int found = 0;
moving to trunk subdir
2010-06-03 21:24:43 +08:00
/* Use the table in main.c */
1. Any test that references nctestserver/NC_findtestserver should be under ENABLE_DAP_REMOTE_TESTS. Fixed to make sure that this is so. Also attempted to fix ncdap_test/CMakeLists.txt, but probably got it wrong. HT to Nico Schlomer. 2. Attempted to reduce the number of conversion errors when -Wconversion is set. Fixed oc2, but rest of netcdf remains to be done. HT to Nico Schlomer. 3. When doing #2, I discovered an error in ncgen.y that has remained hidden. This required some other test case fixes.
2014-03-09 11:41:30 +08:00
for(kvalue = legalkinds; kvalue->name; kvalue++) {
Addressed UNIX API issues reported by clang.
2015-06-19 04:31:10 +08:00
if(sdata) {
if(strcmp(sdata, kvalue->name) == 0) {
Add provenance info for netcdf-4 files. This consists of a persistent attribute named _NCProperties plus two computed attributes _IsNetcdf4 and _SuperblockVersion. See the 'Provenance Attributes' section of docs/attribute_conventions.md for details.
2016-05-04 11:17:06 +08:00
globalspecials._Format = kvalue->k_flag;
/*Main.*/format_attribute = 1;
Addressed UNIX API issues reported by clang.
2015-06-19 04:31:10 +08:00
found = 1;
break;
}
}
moving to trunk subdir
2010-06-03 21:24:43 +08:00
}
if(!found)
derror("_Format: illegal value: %s",sdata);
Add provenance info for netcdf-4 files. This consists of a persistent attribute named _NCProperties plus two computed attributes _IsNetcdf4 and _SuperblockVersion. See the 'Provenance Attributes' section of docs/attribute_conventions.md for details.
2016-05-04 11:17:06 +08:00
} else if((GLOBAL_SPECIAL & tag) != 0) {
if(tag == _ISNETCDF4_FLAG)
globalspecials._IsNetcdf4 = tf;
else if(tag == _SUPERBLOCK_FLAG)
globalspecials._Superblock = idata;
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
else if(tag == _NCPROPS_FLAG) {
globalspecials._NCProperties = sdata;
sdata = NULL;
Fix errors when building on big-endian machine re: issue https://github.com/Unidata/netcdf-c/issues/1278 re: issue https://github.com/Unidata/netcdf-c/issues/876 re: issue https://github.com/Unidata/netcdf-c/issues/806 * Major change to the handling of 8-byte parameters for nc_def_var_filter. The old code was not well thought out. * The new algorithm is documented in docs/filters.md. * Added new utility file plugins/H5Zutil.c to support * Modified plugins/H5Zmisc.c to use new algorithm the new algorithm. * Renamed include/ncfilter.h to include/netcdf_filter.h and made it an installed header so clients can access the new algorithm utility. * Fixed nc_test4/tst_filterparser.c and nc_test4/test_filter_misc.c to use the new algorithm * libdap4/ fixes: * d4swap.c has an error in the endian pre-processing such that record counts were not being swapped correctly. * d4data.c had an error in that checksums were being computed after endian swapping rather than before. * ocinitialize() was never being called, so xxdr bigendian handling was never set correctly. * Required adding debug statements to occompile * Found and fixed memory leak in ncdump.c Not tested: * HDF4 * Pnetcdf * parallel HDF5
2019-02-01 12:13:06 +08:00
}
1. Any test that references nctestserver/NC_findtestserver should be under ENABLE_DAP_REMOTE_TESTS. Fixed to make sure that this is so. Also attempted to fix ncdap_test/CMakeLists.txt, but probably got it wrong. HT to Nico Schlomer. 2. Attempted to reduce the number of conversion errors when -Wconversion is set. Fixed oc2, but rest of netcdf remains to be done. HT to Nico Schlomer. 3. When doing #2, I discovered an error in ncgen.y that has remained hidden. This required some other test case fixes.
2014-03-09 11:41:30 +08:00
} else {
Specialdata* special;
/* Set up special info */
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
if(vsym->var.special == NULL) {
vsym->var.special = ecalloc(sizeof(Specialdata));
if(vsym->var.special == NULL)
derror("Out of memory");
}
special = vsym->var.special;
1. Any test that references nctestserver/NC_findtestserver should be under ENABLE_DAP_REMOTE_TESTS. Fixed to make sure that this is so. Also attempted to fix ncdap_test/CMakeLists.txt, but probably got it wrong. HT to Nico Schlomer. 2. Attempted to reduce the number of conversion errors when -Wconversion is set. Fixed oc2, but rest of netcdf remains to be done. HT to Nico Schlomer. 3. When doing #2, I discovered an error in ncgen.y that has remained hidden. This required some other test case fixes.
2014-03-09 11:41:30 +08:00
if(tag == _FILLVALUE_FLAG) {
/* fillvalue must be a single value*/
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
if(!isconst && datalistlen(list) != 1)
1. Any test that references nctestserver/NC_findtestserver should be under ENABLE_DAP_REMOTE_TESTS. Fixed to make sure that this is so. Also attempted to fix ncdap_test/CMakeLists.txt, but probably got it wrong. HT to Nico Schlomer. 2. Attempted to reduce the number of conversion errors when -Wconversion is set. Fixed oc2, but rest of netcdf remains to be done. HT to Nico Schlomer. 3. When doing #2, I discovered an error in ncgen.y that has remained hidden. This required some other test case fixes.
2014-03-09 11:41:30 +08:00
derror("_FillValue: must be a single (possibly compound) value",
vsym->name);
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
if(isconst) {
list = const2list(con);
con = NULL;
}
1. Any test that references nctestserver/NC_findtestserver should be under ENABLE_DAP_REMOTE_TESTS. Fixed to make sure that this is so. Also attempted to fix ncdap_test/CMakeLists.txt, but probably got it wrong. HT to Nico Schlomer. 2. Attempted to reduce the number of conversion errors when -Wconversion is set. Fixed oc2, but rest of netcdf remains to be done. HT to Nico Schlomer. 3. When doing #2, I discovered an error in ncgen.y that has remained hidden. This required some other test case fixes.
2014-03-09 11:41:30 +08:00
/* check that the attribute value contains no fill values*/
if(containsfills(list)) {
derror("Attribute data may not contain fill values (i.e. _ )");
moving to trunk subdir
2010-06-03 21:24:43 +08:00
}
1. Any test that references nctestserver/NC_findtestserver should be under ENABLE_DAP_REMOTE_TESTS. Fixed to make sure that this is so. Also attempted to fix ncdap_test/CMakeLists.txt, but probably got it wrong. HT to Nico Schlomer. 2. Attempted to reduce the number of conversion errors when -Wconversion is set. Fixed oc2, but rest of netcdf remains to be done. HT to Nico Schlomer. 3. When doing #2, I discovered an error in ncgen.y that has remained hidden. This required some other test case fixes.
2014-03-09 11:41:30 +08:00
/* _FillValue is also a real attribute*/
if(vsym->objectclass != NC_VAR) {
derror("_FillValue attribute not associated with variable: %s",vsym->name);
}
if(tsym == NULL) tsym = vsym->typ.basetype;
else if(vsym->typ.basetype != tsym) {
derror("_FillValue attribute type does not match variable type: %s",vsym->name);
}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
special->_Fillvalue = clonedatalist(list);
/* Create the corresponding attribute */
1. Any test that references nctestserver/NC_findtestserver should be under ENABLE_DAP_REMOTE_TESTS. Fixed to make sure that this is so. Also attempted to fix ncdap_test/CMakeLists.txt, but probably got it wrong. HT to Nico Schlomer. 2. Attempted to reduce the number of conversion errors when -Wconversion is set. Fixed oc2, but rest of netcdf remains to be done. HT to Nico Schlomer. 3. When doing #2, I discovered an error in ncgen.y that has remained hidden. This required some other test case fixes.
2014-03-09 11:41:30 +08:00
attr = makeattribute(install("_FillValue"),vsym,tsym,list,ATTRVAR);
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
list = NULL;
1. Any test that references nctestserver/NC_findtestserver should be under ENABLE_DAP_REMOTE_TESTS. Fixed to make sure that this is so. Also attempted to fix ncdap_test/CMakeLists.txt, but probably got it wrong. HT to Nico Schlomer. 2. Attempted to reduce the number of conversion errors when -Wconversion is set. Fixed oc2, but rest of netcdf remains to be done. HT to Nico Schlomer. 3. When doing #2, I discovered an error in ncgen.y that has remained hidden. This required some other test case fixes.
2014-03-09 11:41:30 +08:00
} else switch (tag) {
merge-squash
2015-08-16 06:26:35 +08:00
/* These will be output as attributes later */
Moved libsrc5 to libsrcp because pnetcdf is used for more than CDF-5 files.
2015-08-15 10:38:30 +08:00
case _STORAGE_FLAG:
if(!sdata)
derror("_Storage: illegal NULL value");
else if(strcmp(sdata,"contiguous") == 0)
special->_Storage = NC_CONTIGUOUS;
else if(strcmp(sdata,"chunked") == 0)
special->_Storage = NC_CHUNKED;
else
derror("_Storage: illegal value: %s",sdata);
special->flags |= _STORAGE_FLAG;
break;
case _FLETCHER32_FLAG:
1. Any test that references nctestserver/NC_findtestserver should be under ENABLE_DAP_REMOTE_TESTS. Fixed to make sure that this is so. Also attempted to fix ncdap_test/CMakeLists.txt, but probably got it wrong. HT to Nico Schlomer. 2. Attempted to reduce the number of conversion errors when -Wconversion is set. Fixed oc2, but rest of netcdf remains to be done. HT to Nico Schlomer. 3. When doing #2, I discovered an error in ncgen.y that has remained hidden. This required some other test case fixes.
2014-03-09 11:41:30 +08:00
special->_Fletcher32 = tf;
special->flags |= _FLETCHER32_FLAG;
break;
case _DEFLATE_FLAG:
special->_DeflateLevel = idata;
special->flags |= _DEFLATE_FLAG;
break;
case _SHUFFLE_FLAG:
special->_Shuffle = tf;
special->flags |= _SHUFFLE_FLAG;
break;
case _ENDIAN_FLAG:
Addressed UNIX API issues reported by clang.
2015-06-19 04:31:10 +08:00
if(!sdata)
Moved libsrc5 to libsrcp because pnetcdf is used for more than CDF-5 files.
2015-08-15 10:38:30 +08:00
derror("_Endianness: illegal NULL value");
Addressed UNIX API issues reported by clang.
2015-06-19 04:31:10 +08:00
else if(strcmp(sdata,"little") == 0)
special->_Endianness = 1;
else if(strcmp(sdata,"big") == 0)
special->_Endianness = 2;
else
derror("_Endianness: illegal value: %s",sdata);
special->flags |= _ENDIAN_FLAG;
break;
case _NOFILL_FLAG:
1. Any test that references nctestserver/NC_findtestserver should be under ENABLE_DAP_REMOTE_TESTS. Fixed to make sure that this is so. Also attempted to fix ncdap_test/CMakeLists.txt, but probably got it wrong. HT to Nico Schlomer. 2. Attempted to reduce the number of conversion errors when -Wconversion is set. Fixed oc2, but rest of netcdf remains to be done. HT to Nico Schlomer. 3. When doing #2, I discovered an error in ncgen.y that has remained hidden. This required some other test case fixes.
2014-03-09 11:41:30 +08:00
special->_Fill = (1 - tf); /* negate */
special->flags |= _NOFILL_FLAG;
break;
Add provenance info for netcdf-4 files. This consists of a persistent attribute named _NCProperties plus two computed attributes _IsNetcdf4 and _SuperblockVersion. See the 'Provenance Attributes' section of docs/attribute_conventions.md for details.
2016-05-04 11:17:06 +08:00
case _CHUNKSIZES_FLAG: {
1. Any test that references nctestserver/NC_findtestserver should be under ENABLE_DAP_REMOTE_TESTS. Fixed to make sure that this is so. Also attempted to fix ncdap_test/CMakeLists.txt, but probably got it wrong. HT to Nico Schlomer. 2. Attempted to reduce the number of conversion errors when -Wconversion is set. Fixed oc2, but rest of netcdf remains to be done. HT to Nico Schlomer. 3. When doing #2, I discovered an error in ncgen.y that has remained hidden. This required some other test case fixes.
2014-03-09 11:41:30 +08:00
int i;
Fix errors when building on big-endian machine re: issue https://github.com/Unidata/netcdf-c/issues/1278 re: issue https://github.com/Unidata/netcdf-c/issues/876 re: issue https://github.com/Unidata/netcdf-c/issues/806 * Major change to the handling of 8-byte parameters for nc_def_var_filter. The old code was not well thought out. * The new algorithm is documented in docs/filters.md. * Added new utility file plugins/H5Zutil.c to support * Modified plugins/H5Zmisc.c to use new algorithm the new algorithm. * Renamed include/ncfilter.h to include/netcdf_filter.h and made it an installed header so clients can access the new algorithm utility. * Fixed nc_test4/tst_filterparser.c and nc_test4/test_filter_misc.c to use the new algorithm * libdap4/ fixes: * d4swap.c has an error in the endian pre-processing such that record counts were not being swapped correctly. * d4data.c had an error in that checksums were being computed after endian swapping rather than before. * ocinitialize() was never being called, so xxdr bigendian handling was never set correctly. * Required adding debug statements to occompile * Found and fixed memory leak in ncdump.c Not tested: * HDF4 * Pnetcdf * parallel HDF5
2019-02-01 12:13:06 +08:00
list = (isconst ? const2list(con) : list);
1. Any test that references nctestserver/NC_findtestserver should be under ENABLE_DAP_REMOTE_TESTS. Fixed to make sure that this is so. Also attempted to fix ncdap_test/CMakeLists.txt, but probably got it wrong. HT to Nico Schlomer. 2. Attempted to reduce the number of conversion errors when -Wconversion is set. Fixed oc2, but rest of netcdf remains to be done. HT to Nico Schlomer. 3. When doing #2, I discovered an error in ncgen.y that has remained hidden. This required some other test case fixes.
2014-03-09 11:41:30 +08:00
special->nchunks = list->length;
Cleanup ncgen memory management
2017-10-31 05:52:08 +08:00
special->_ChunkSizes = (size_t*)ecalloc(sizeof(size_t)*special->nchunks);
1. Any test that references nctestserver/NC_findtestserver should be under ENABLE_DAP_REMOTE_TESTS. Fixed to make sure that this is so. Also attempted to fix ncdap_test/CMakeLists.txt, but probably got it wrong. HT to Nico Schlomer. 2. Attempted to reduce the number of conversion errors when -Wconversion is set. Fixed oc2, but rest of netcdf remains to be done. HT to Nico Schlomer. 3. When doing #2, I discovered an error in ncgen.y that has remained hidden. This required some other test case fixes.
2014-03-09 11:41:30 +08:00
for(i=0;i<special->nchunks;i++) {
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
tmp = nullconst();
tmp->nctype = NC_INT;
convert1(list->data[i],tmp);
if(tmp->nctype == NC_INT) {
special->_ChunkSizes[i] = (size_t)tmp->value.int32v;
1. Any test that references nctestserver/NC_findtestserver should be under ENABLE_DAP_REMOTE_TESTS. Fixed to make sure that this is so. Also attempted to fix ncdap_test/CMakeLists.txt, but probably got it wrong. HT to Nico Schlomer. 2. Attempted to reduce the number of conversion errors when -Wconversion is set. Fixed oc2, but rest of netcdf remains to be done. HT to Nico Schlomer. 3. When doing #2, I discovered an error in ncgen.y that has remained hidden. This required some other test case fixes.
2014-03-09 11:41:30 +08:00
} else {
efree(special->_ChunkSizes);
derror("%s: illegal value",specialname(tag));
}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
reclaimconstant(tmp);
1. Any test that references nctestserver/NC_findtestserver should be under ENABLE_DAP_REMOTE_TESTS. Fixed to make sure that this is so. Also attempted to fix ncdap_test/CMakeLists.txt, but probably got it wrong. HT to Nico Schlomer. 2. Attempted to reduce the number of conversion errors when -Wconversion is set. Fixed oc2, but rest of netcdf remains to be done. HT to Nico Schlomer. 3. When doing #2, I discovered an error in ncgen.y that has remained hidden. This required some other test case fixes.
2014-03-09 11:41:30 +08:00
}
special->flags |= _CHUNKSIZES_FLAG;
/* Chunksizes => storage == chunked */
special->flags |= _STORAGE_FLAG;
special->_Storage = NC_CHUNKED;
} break;
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
case _FILTER_FLAG:
This is the initial step in moving to the new higher performance (I hope) metadata mechanism. This mostly just adds new pieces of code (e.g. nclistmap) and does some minor fixes. It should be transparent to everything else. The next set of changes will be the big step.
2018-02-09 10:53:40 +08:00
#ifdef USE_NETCDF4
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
/* Parse the filter spec */
This is the initial step in moving to the new higher performance (I hope) metadata mechanism. This mostly just adds new pieces of code (e.g. nclistmap) and does some minor fixes. It should be transparent to everything else. The next set of changes will be the big step.
2018-02-09 10:53:40 +08:00
if(parsefilterflag(sdata,special) == NC_NOERR)
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
special->flags |= _FILTER_FLAG;
This is the initial step in moving to the new higher performance (I hope) metadata mechanism. This mostly just adds new pieces of code (e.g. nclistmap) and does some minor fixes. It should be transparent to everything else. The next set of changes will be the big step.
2018-02-09 10:53:40 +08:00
else {
efree(special->_FilterParams);
Spelling fixes
2019-09-18 10:27:43 +08:00
derror("_Filter: unparsable filter spec: %s",sdata);
This is the initial step in moving to the new higher performance (I hope) metadata mechanism. This mostly just adds new pieces of code (e.g. nclistmap) and does some minor fixes. It should be transparent to everything else. The next set of changes will be the big step.
2018-02-09 10:53:40 +08:00
}
#else
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
derror("%s: the filter attribute requires netcdf-4 to be enabled",specialname(tag));
This is the initial step in moving to the new higher performance (I hope) metadata mechanism. This mostly just adds new pieces of code (e.g. nclistmap) and does some minor fixes. It should be transparent to everything else. The next set of changes will be the big step.
2018-02-09 10:53:40 +08:00
#endif
Finalize the compression support. This relies on the HDF5 capability to dynamically load compression filters. Note that a compression filter is just a subcase of filters. The primary user-visible changes are as follows: 1. Add a standard header "netcdf_filter.h" that defines the necessary API extensions 2. Modify ncgen to support two new special attributes "_Filter_ID" and "_Filter_Parameters" so that compression can be turned on when creating a file using ncgen. 4. Add a detailed description of filtering support to the user's guide; see the file filters.md 5. Add a test case directory for this: nc_test4/filter_test. It is fragile and a ./configure flags (-enable-filter-test) is defined (default disabled) to shut this off this test to avoid spurious 'make check' failures. Note that the HDF5 documentation is not up-to-date, so much of what is encoded here comes from examining the actual code in the file H5PL.c in the HDF5 source code.
2017-04-28 03:01:59 +08:00
break;
1. Any test that references nctestserver/NC_findtestserver should be under ENABLE_DAP_REMOTE_TESTS. Fixed to make sure that this is so. Also attempted to fix ncdap_test/CMakeLists.txt, but probably got it wrong. HT to Nico Schlomer. 2. Attempted to reduce the number of conversion errors when -Wconversion is set. Fixed oc2, but rest of netcdf remains to be done. HT to Nico Schlomer. 3. When doing #2, I discovered an error in ncgen.y that has remained hidden. This required some other test case fixes.
2014-03-09 11:41:30 +08:00
default: PANIC1("makespecial: illegal token: %d",tag);
}
}
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
if(sdata) efree(sdata);
if(con) reclaimconstant(con);
if(list) reclaimdatalist(list);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
return attr;
}
static Symbol*
makeattribute(Symbol* asym,
Symbol* vsym,
Symbol* tsym,
Datalist* data,
Attrkind kind) /* global var or unknown*/
{
asym->objectclass = NC_ATT;
asym->data = data;
switch (kind) {
case ATTRVAR:
asym->att.var = vsym;
asym->typ.basetype = tsym;
update utilities: list,byte,hash,uri,log
2012-08-20 05:54:30 +08:00
listpush(attdefs,(void*)asym);
Add provenance info for netcdf-4 files. This consists of a persistent attribute named _NCProperties plus two computed attributes _IsNetcdf4 and _SuperblockVersion. See the 'Provenance Attributes' section of docs/attribute_conventions.md for details.
2016-05-04 11:17:06 +08:00
addtogroup(asym);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
case ATTRGLOBAL:
asym->att.var = NULL; /* NULL => NC_GLOBAL*/
asym->typ.basetype = tsym;
Oops, forgot to test nc3 only. Fixed some errors from that case.
2016-05-06 05:59:54 +08:00
listpush(gattdefs,(void*)asym);
addtogroup(asym);
moving to trunk subdir
2010-06-03 21:24:43 +08:00
break;
default: PANIC1("unexpected attribute type: %d",kind);
}
/* finally; check that the attribute value contains no fill values*/
if(containsfills(data)) {
derror("Attribute data may not contain fill values (i.e. _ ): %s",asym->name);
}
return asym;
}
Add provenance info for netcdf-4 files. This consists of a persistent attribute named _NCProperties plus two computed attributes _IsNetcdf4 and _SuperblockVersion. See the 'Provenance Attributes' section of docs/attribute_conventions.md for details.
2016-05-04 11:17:06 +08:00
static long long
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
extractint(NCConstant* con)
Add provenance info for netcdf-4 files. This consists of a persistent attribute named _NCProperties plus two computed attributes _IsNetcdf4 and _SuperblockVersion. See the 'Provenance Attributes' section of docs/attribute_conventions.md for details.
2016-05-04 11:17:06 +08:00
{
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
switch (con->nctype) {
case NC_BYTE: return (long long)(con->value.int8v);
case NC_SHORT: return (long long)(con->value.int16v);
case NC_INT: return (long long)(con->value.int32v);
case NC_UBYTE: return (long long)(con->value.uint8v);
case NC_USHORT: return (long long)(con->value.uint16v);
case NC_UINT: return (long long)(con->value.uint32v);
case NC_INT64: return (long long)(con->value.int64v);
Add provenance info for netcdf-4 files. This consists of a persistent attribute named _NCProperties plus two computed attributes _IsNetcdf4 and _SuperblockVersion. See the 'Provenance Attributes' section of docs/attribute_conventions.md for details.
2016-05-04 11:17:06 +08:00
default:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
derror("Not a signed integer type: %d",con->nctype);
Add provenance info for netcdf-4 files. This consists of a persistent attribute named _NCProperties plus two computed attributes _IsNetcdf4 and _SuperblockVersion. See the 'Provenance Attributes' section of docs/attribute_conventions.md for details.
2016-05-04 11:17:06 +08:00
break;
}
return 0;
}
moving to trunk subdir
2010-06-03 21:24:43 +08:00
static int
containsfills(Datalist* list)
{
Resolve Lynton's vlen problems (partially) re: jira NCF-145
2012-02-14 08:25:32 +08:00
if(list != NULL) {
int i;
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
NCConstant** cons = list->data;
for(i=0;i<list->length;i++) {
if(cons[i]->nctype == NC_COMPOUND) {
if(containsfills(cons[i]->value.compoundv)) return 1;
} else if(cons[i]->nctype == NC_FILLVALUE)
Cleanup some ncgen memory problems
2017-11-01 04:03:57 +08:00
return 1;
Resolve Lynton's vlen problems (partially) re: jira NCF-145
2012-02-14 08:25:32 +08:00
}
moving to trunk subdir
2010-06-03 21:24:43 +08:00
}
return 0;
}
1. Keep up to date by merging master 2. Factored out the parameter string parsing for ncgen and nccopy int libdispatch/dfilter.c + include/ncfilter.h 3. Allow a parameter string to use constant types other than unsigned int. See docs/filters.md for details. 4. Moved the old content of include/netcdf_filter.h into include/netcdf.h and removed include/netcdf_filter.h as no longer needed. 5. Force the test filter (bzip2) in nc_test4/filter_test to be built using BUILT_SOURCES.
2017-10-09 05:56:45 +08:00
/*
Try to infer the file type from the
kinds of constructs used in the cdl file.
*/
Fixed the following Jira minor bugs: NCF-42: _Format attribute sometimes being ignored NCF-43: Fixed unsigned long long parsing. NCF-47: Make opendap code properly handle illegal names like "x.y" by supressing them NCF-49: check for uint type NCF-50: properly handle username:pwd embedded in urls.
2011-05-13 01:51:32 +08:00
static void
1. There were several bugs in ncdump/dumplib.c that were not taking the CDF-5 format into account. 2. Had to update ncgen.1 man page to define the new k-flag rules to deal with cdf-5. 3. Had to fix some tests that use 'cmp' for comparison; this really should be deprecated. 3. There was a bug in configure.ac with respect to using the enable-netcdf-4 flag vs using disable-netcdf-4.
2015-11-07 08:03:28 +08:00
vercheck(int tid)
Fixed the following Jira minor bugs: NCF-42: _Format attribute sometimes being ignored NCF-43: Fixed unsigned long long parsing. NCF-47: Make opendap code properly handle illegal names like "x.y" by supressing them NCF-49: check for uint type NCF-50: properly handle username:pwd embedded in urls.
2011-05-13 01:51:32 +08:00
{
1. There were several bugs in ncdump/dumplib.c that were not taking the CDF-5 format into account. 2. Had to update ncgen.1 man page to define the new k-flag rules to deal with cdf-5. 3. Had to fix some tests that use 'cmp' for comparison; this really should be deprecated. 3. There was a bug in configure.ac with respect to using the enable-netcdf-4 flag vs using disable-netcdf-4.
2015-11-07 08:03:28 +08:00
switch (tid) {
1. Keep up to date by merging master 2. Factored out the parameter string parsing for ncgen and nccopy int libdispatch/dfilter.c + include/ncfilter.h 3. Allow a parameter string to use constant types other than unsigned int. See docs/filters.md for details. 4. Moved the old content of include/netcdf_filter.h into include/netcdf.h and removed include/netcdf_filter.h as no longer needed. 5. Force the test filter (bzip2) in nc_test4/filter_test to be built using BUILT_SOURCES.
2017-10-09 05:56:45 +08:00
case NC_UBYTE: markcdf4("netCDF4/5 type: UBYTE"); break;
case NC_USHORT: markcdf4("netCDF4/5 type: USHORT"); break;
case NC_UINT: markcdf4("netCDF4/5 type: UINT"); break;
case NC_INT64: markcdf4("netCDF4/5 type: INT64"); break;
case NC_UINT64: markcdf4("netCDF4/5 type: UINT64"); break;
1. There were several bugs in ncdump/dumplib.c that were not taking the CDF-5 format into account. 2. Had to update ncgen.1 man page to define the new k-flag rules to deal with cdf-5. 3. Had to fix some tests that use 'cmp' for comparison; this really should be deprecated. 3. There was a bug in configure.ac with respect to using the enable-netcdf-4 flag vs using disable-netcdf-4.
2015-11-07 08:03:28 +08:00
case NC_STRING: markcdf4("netCDF4 type: STRING"); break;
case NC_VLEN: markcdf4("netCDF4 type: VLEN"); break;
case NC_OPAQUE: markcdf4("netCDF4 type: OPAQUE"); break;
case NC_ENUM: markcdf4("netCDF4 type: ENUM"); break;
case NC_COMPOUND: markcdf4("netCDF4 type: COMPOUND"); break;
Fixed the following Jira minor bugs: NCF-42: _Format attribute sometimes being ignored NCF-43: Fixed unsigned long long parsing. NCF-47: Make opendap code properly handle illegal names like "x.y" by supressing them NCF-49: check for uint type NCF-50: properly handle username:pwd embedded in urls.
2011-05-13 01:51:32 +08:00
default: break;
}
}
Add provenance info for netcdf-4 files. This consists of a persistent attribute named _NCProperties plus two computed attributes _IsNetcdf4 and _SuperblockVersion. See the 'Provenance Attributes' section of docs/attribute_conventions.md for details.
2016-05-04 11:17:06 +08:00
const char*
specialname(int tag)
{
struct Specialtoken* spp = specials;
for(;spp->name;spp++) {
if(spp->tag == tag)
return spp->name;
}
return "<unknown>";
}
This is the initial step in moving to the new higher performance (I hope) metadata mechanism. This mostly just adds new pieces of code (e.g. nclistmap) and does some minor fixes. It should be transparent to everything else. The next set of changes will be the big step.
2018-02-09 10:53:40 +08:00
#ifdef USE_NETCDF4
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
/*
Parse a filter spec string and store it in special
*/
static int
This is the initial step in moving to the new higher performance (I hope) metadata mechanism. This mostly just adds new pieces of code (e.g. nclistmap) and does some minor fixes. It should be transparent to everything else. The next set of changes will be the big step.
2018-02-09 10:53:40 +08:00
parsefilterflag(const char* sdata, Specialdata* special)
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
{
This is the initial step in moving to the new higher performance (I hope) metadata mechanism. This mostly just adds new pieces of code (e.g. nclistmap) and does some minor fixes. It should be transparent to everything else. The next set of changes will be the big step.
2018-02-09 10:53:40 +08:00
int stat = NC_NOERR;
Replaced the overwritten updated parsefilterflag
2017-11-14 04:19:46 +08:00
This is the initial step in moving to the new higher performance (I hope) metadata mechanism. This mostly just adds new pieces of code (e.g. nclistmap) and does some minor fixes. It should be transparent to everything else. The next set of changes will be the big step.
2018-02-09 10:53:40 +08:00
if(sdata == NULL || strlen(sdata) == 0) return NC_EINVAL;
Replaced the overwritten updated parsefilterflag
2017-11-14 04:19:46 +08:00
This is the initial step in moving to the new higher performance (I hope) metadata mechanism. This mostly just adds new pieces of code (e.g. nclistmap) and does some minor fixes. It should be transparent to everything else. The next set of changes will be the big step.
2018-02-09 10:53:40 +08:00
stat = NC_parsefilterspec(sdata, &special->_FilterID, &special->nparams, &special->_FilterParams);
if(stat)
derror("Malformed filter spec: %s",sdata);
return stat;
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
}
This is the initial step in moving to the new higher performance (I hope) metadata mechanism. This mostly just adds new pieces of code (e.g. nclistmap) and does some minor fixes. It should be transparent to everything else. The next set of changes will be the big step.
2018-02-09 10:53:40 +08:00
#endif
Add new capabilities to filter code: 1. Allow nccopy to apply filters, especially on the output file. This provides a third way to do this other than using ncgen or programatically 2. Make sure that even if the filter code is not available, it is possible to see the filter id and parameters for variables using e.g ncdump -hs. 3. Fix bug in nccopy so that the input file does not necessarily have to be netcdf-4. 4. At last minute decided to change to using a single "_Filter" attribute for ncgen 5. Added a test to tst_filter.sh to generate C code using ncgen.
2017-05-15 08:10:02 +08:00
fix NCF-120
2011-09-16 00:57:16 +08:00
/*
2011-09-17 02:36:08 +08:00
Since the arguments are all simple constants,
fix NCF-120
2011-09-16 00:57:16 +08:00
we can evaluate the function immediately
and return its value.
2011-09-17 02:36:08 +08:00
Note that currently, only a single value can
be returned.
fix NCF-120
2011-09-16 00:57:16 +08:00
*/
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
static NCConstant*
fix NCF-120
2011-09-16 00:57:16 +08:00
evaluate(Symbol* fcn, Datalist* arglist)
{
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
NCConstant* result = nullconst();
fix NCF-120
2011-09-16 00:57:16 +08:00
/* prepare the result */
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
result->lineno = fcn->lineno;
fix NCF-120
2011-09-16 00:57:16 +08:00
if(strcasecmp(fcn->name,"time") == 0) {
2011-09-17 02:36:08 +08:00
char* timekind = NULL;
char* timevalue = NULL;
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
result->nctype = NC_DOUBLE;
result->value.doublev = 0;
2011-09-17 02:36:08 +08:00
/* int time([string],string) */
switch (arglist->length) {
case 2:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
if(arglist->data[1]->nctype != NC_STRING) {
2011-09-17 02:36:08 +08:00
derror("Expected function signature: time([string,]string)");
fix NCF-120
2011-09-16 00:57:16 +08:00
goto done;
}
2011-09-17 02:36:08 +08:00
/* fall thru */
case 1:
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
if(arglist->data[0]->nctype != NC_STRING) {
2011-09-17 02:36:08 +08:00
derror("Expected function signature: time([string,]string)");
fix NCF-120
2011-09-16 00:57:16 +08:00
goto done;
}
2011-09-17 02:36:08 +08:00
break;
case 0:
Addressed UNIX API issues reported by clang.
2015-06-19 04:31:10 +08:00
default:
2011-09-17 02:36:08 +08:00
derror("Expected function signature: time([string,]string)");
goto done;
fix NCF-120
2011-09-16 00:57:16 +08:00
}
2011-09-17 02:36:08 +08:00
if(arglist->length == 2) {
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
timekind = arglist->data[0]->value.stringv.stringv;
timevalue = arglist->data[1]->value.stringv.stringv;
2011-09-17 02:36:08 +08:00
} else
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
timevalue = arglist->data[0]->value.stringv.stringv;
2011-09-17 02:36:08 +08:00
if(timekind == NULL) { /* use cd time as the default */
cdCompTime comptime;
CdTime cdtime;
cdCalenType timetype = cdStandard;
cdChar2Comp(timetype,timevalue,&comptime);
/* convert comptime to cdTime */
Addressed UNIX API issues reported by clang.
2015-06-19 04:31:10 +08:00
cdtime.year = comptime.year;
2011-09-17 02:36:08 +08:00
cdtime.month = comptime.month;
Addressed UNIX API issues reported by clang.
2015-06-19 04:31:10 +08:00
cdtime.day = comptime.day;
2011-09-17 02:36:08 +08:00
cdtime.hour = comptime.hour;
cdtime.baseYear = 1970;
cdtime.timeType = CdChron;
/* convert to double value */
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
Cdh2e(&cdtime,&result->value.doublev);
2011-09-17 02:36:08 +08:00
} else {
derror("Time conversion '%s' not supported",timekind);
goto done;
}
} else { /* Unknown function */
fix NCF-120
2011-09-16 00:57:16 +08:00
derror("Unknown function name: %s",fcn->name);
goto done;
}
done:
return result;
}
Reference in New Issue Copy Permalink