diff --git a/CMakeLists.txt b/CMakeLists.txt
index 9ac9330af..fc0c98227 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1027,6 +1027,7 @@ SET(STATUS_ERANGE_FILL "OFF")
OPTION(ENABLE_ERANGE_FILL "Enable use of fill value when out-of-range type conversion causes NC_ERANGE error." OF)
IF(ENABLE_ERANGE_FILL)
SET(STATUS_ERANGE_FILL "ON")
+ ADD_DEFINITIONS(-DERANGE_FILL)
ENDIF()
# Options to use a more relaxed coordinate argument boundary check
diff --git a/configure.ac b/configure.ac
index 9c581c046..9948b0700 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1192,6 +1192,7 @@ if test "x$enable_erange_fill" = xyes ; then
else
M4FLAGS="$M4FLAGS -DERANGE_FILL"
fi
+ AC_DEFINE([ERANGE_FILL], [1], [if true, use _FillValue for NC_ERANGE data elements])
fi
AC_SUBST(M4FLAGS)
diff --git a/docs/guide.dox b/docs/guide.dox
index b3a8c3838..7f57f19bd 100644
--- a/docs/guide.dox
+++ b/docs/guide.dox
@@ -84,7 +84,15 @@ affecting existing programs. The physical representation of netCDF
data is designed to be independent of the computer on which the data
were written.
-Unidata supports the netCDF interfaces for C (see NetCDF-C User's Guide), FORTRAN 77 (see NetCDF Fortran 77 Interface Guide), FORTRAN 90 (see NetCDF Fortran 90 Interface Guide), and C++ (see NetCDF C++ Interface Guide).
+Unidata supports the netCDF interfaces for C (see NetCDF-C User's
+Guide), FORTRAN 77 (see NetCDF Fortran 77 Interface Guide), FORTRAN 90 (see NetCDF Fortran 90 Interface Guide), and C++ (see NetCDF C++ Interface Guide).
The netCDF library is supported for various UNIX operating systems. A
MS Windows port is also available. The software is also ported and
@@ -128,10 +136,11 @@ floating-point standard is used for floating-point data
representation.
Descriptions of the overall structure of netCDF classic and 64-bit
-offset files are provided later in this manual. See Structure.
+offset files are provided later in this manual. See
+\ref file_structure_and_performance.
The details of the classic and 64-bit offset formats are described in
-an appendix. See File Format. However, users are discouraged from
+an appendix. See \ref netcdf_format. However, users are discouraged from
using the format specification to develop independent low-level
software for reading and writing netCDF files, because this could lead
to compatibility problems if the format is ever modified.
@@ -154,15 +163,14 @@ Users are encouraged to use netCDF classic format to distribute data,
for maximum portability.
To select 64-bit offset or netCDF-4 format files, C programmers should
-use flag NC_64BIT_OFFSET or NC_NETCDF4 in function nc_create. See
-nc_create.
+use flag NC_64BIT_OFFSET or NC_NETCDF4 in function nc_create().
In Fortran, use flag nf_64bit_offset or nf_format_netcdf4 in function
NF_CREATE. See NF_CREATE.
It is also possible to change the default creation format, to convert
a large body of code without changing every create call. C programmers
-see nc_set_default_format. Fortran programs see NF_SET_DEFAULT_FORMAT.
+see nc_set_default_format(). Fortran programs see NF_SET_DEFAULT_FORMAT.
\subsection classic_format NetCDF Classic Format
@@ -176,12 +184,13 @@ previous version of netCDF. It has maximum portability, and is still
the default netCDF format.
For some users, the various 2 GiB format limitations of the classic
-format become a problem. (see Classic Limitations). 1.4.2 NetCDF
-64-bit Offset Format
+format become a problem. (see \ref limitations).
+
+\subsection netcdf_64bit_offset_format NetCDF 64-bit Offset Format
For these users, 64-bit offset format is a natural choice. It greatly
-eases the size restrictions of netCDF classic files (see 64 bit Offset
-Limitations).
+eases the size restrictions of netCDF classic files (see \ref
+limitations).
Files with the 64-bit offsets are identified with a “CDF\002” at the
beginning of the file. In this documentation this format is called
@@ -211,7 +220,9 @@ NetCDF-4 files can't be read by any version of the netCDF library
previous to 4.0. (But they can be read by HDF5, version 1.8.0 or
better).
-For more discussion of format issues see The NetCDF Tutorial.
+For more discussion of format issues see The
+NetCDF Tutorial.
\section architecture NetCDF Library Architecture
@@ -250,7 +261,7 @@ designing and implementing netCDF, it is still possible to use the
netCDF interface to access data in inefficient ways: for example, by
requesting a slice of data that requires a single value from each
record. Advice on how to use the interface efficiently is provided in
-Structure.
+\ref file_structure_and_performance.
The use of HDF5 as a data format adds significant overhead in metadata
operations, less so in data access operations. We continue to study
@@ -269,7 +280,7 @@ Attributes play a vital role in providing ancillary information. It is
important to use all the relevant standard attributes using the
relevant conventions. For a description of reserved attributes (used
by the netCDF library) and attribute conventions for generic
-application software, see Attribute Conventions.
+application software, see \ref attribute_conventions.
A number of groups have defined their own additional conventions and
styles for netCDF data. Descriptions of these conventions, as well as
@@ -303,19 +314,19 @@ COMPOUND types allow users to organize data in new ways.
With the classic netCDF file format, there are constraints that limit
how a dataset is structured to store more than 2 GiBytes (a GiByte is
2^30 or 1,073,741,824 bytes, as compared to a Gbyte, which is
-1,000,000,000 bytes.) of data in a single netCDF dataset. (see Classic
-Limitations). This limitation is a result of 32-bit offsets used for
+1,000,000,000 bytes.) of data in a single netCDF dataset. (see \ref
+limitations). This limitation is a result of 32-bit offsets used for
storing relative offsets within a classic netCDF format file. Since
one of the goals of netCDF is portable data, and some file systems
still can't deal with files larger than 2 GiB, it is best to keep
files that must be portable below this limit. Nevertheless, it is
possible to create and access netCDF files larger than 2 GiB on
-platforms that provide support for such files (see Large File
-Support).
+platforms that provide support for such files (see
+\ref large_file_support).
The new 64-bit offset format allows large files, and makes it easy to
create to create fixed variables of about 4 GiB, and record variables
-of about 4 GiB per record. (see 64 bit Offset Limitations). However,
+of about 4 GiB per record. (see \ref netcdf_64bit_offset_format). However,
old netCDF applications will not be able to read the 64-bit offset
files until they are upgraded to at least version 3.6.0 of netCDF
(i.e. the version in which 64-bit offset format was introduced).
@@ -543,17 +554,17 @@ for variables with dimensions, or
for scalar variables.
In the above CDL example there are six variables. As discussed below,
-four of these are coordinate variables (See coordinate_variables). The
-remaining variables (sometimes called primary variables), temp and rh,
-contain what is usually thought of as the data. Each of these
-variables has the unlimited dimension time as its first dimension, so
-they are called record variables. A variable that is not a record
-variable has a fixed length (number of data values) given by the
-product of its dimension lengths. The length of a record variable is
-also the product of its dimension lengths, but in this case the
-product is variable because it involves the length of the unlimited
-dimension, which can vary. The length of the unlimited dimension is
-the number of records.
+four of these are coordinate variables (See \ref
+coordinate_variables). The remaining variables (sometimes called
+primary variables), temp and rh, contain what is usually thought of as
+the data. Each of these variables has the unlimited dimension time as
+its first dimension, so they are called record variables. A variable
+that is not a record variable has a fixed length (number of data
+values) given by the product of its dimension lengths. The length of a
+record variable is also the product of its dimension lengths, but in
+this case the product is variable because it involves the length of
+the unlimited dimension, which can vary. The length of the unlimited
+dimension is the number of records.
\section coordinate_variables Coordinate Variables
@@ -653,7 +664,7 @@ For the netCDF classic model, the type and length of each attribute
are not explicitly declared in CDL; they are derived from the values
assigned to the attribute. All values of an attribute must be of the
same type. The notation used for constant values of the various netCDF
-types is discussed later (see CDL Constants).
+types is discussed later (see \ref cdl_syntax).
The extended CDL syntax for the enhanced data model supported by
netCDF-4 allows optional type specifications, including user-defined
@@ -677,13 +688,13 @@ attribute conventions and it is strongly recommended that these be
followed unless there are good reasons for not doing so. For
information about units, long_name, valid_min, valid_max, valid_range,
scale_factor, add_offset, _FillValue, and other conventional
-attributes, see Attribute Conventions.
+attributes, see \ref attribute_conventions.
Attributes may be added to a netCDF dataset long after it is first
defined, so you don't have to anticipate all potentially useful
attributes. However adding new attributes to an existing classic or
64-bit offset format dataset can incur the same expense as copying the
-dataset. For a more extensive discussion see Structure.
+dataset. For a more extensive discussion see \ref file_structure_and_performance.
\section differences_atts_vars Differences between Attributes and Variables
@@ -751,7 +762,10 @@ characters.
Some widely used conventions restrict names to only alphanumeric
characters or underscores.
-\note Note that, when using the DAP2 protocol to access netCDF data, there are \em reserved keywords, the use of which may result in undefined behavior. See \ref dap2_reserved_keywords for more information.
+\note Note that, when using the DAP2 protocol to access netCDF data,
+there are \em reserved keywords, the use of which may result in
+undefined behavior. See \ref dap2_reserved_keywords for more
+information.
\section archival Is NetCDF a Good Archive Format?
@@ -1082,11 +1096,11 @@ access.
\section c_array_section_access A C Example of Array-Section Access
-Assume that in our earlier example of a netCDF dataset (see Network
-Common Data Form Language (CDL)), we wish to read a cross-section of
-all the data for the temp variable at one level (say, the second), and
-assume that there are currently three records (time values) in the
-netCDF dataset. Recall that the dimensions are defined as
+Assume that in our earlier example of a netCDF dataset, we wish to
+read a cross-section of all the data for the temp variable at one
+level (say, the second), and assume that there are currently three
+records (time values) in the netCDF dataset. Recall that the
+dimensions are defined as
\code
lat = 5, lon = 10, level = 4, time = unlimited;
@@ -1251,24 +1265,22 @@ datasets self-describing. A disadvantage of this organization is that
any operation on a netCDF dataset that requires the header to grow
(or, less likely, to shrink), for example adding new dimensions or new
variables, requires moving the data by copying it. This expense is
-incurred when the enddef function is called: nc_enddef in C (see
-nc_enddef), NF_ENDDEF in Fortran (see NF_ENDDEF), after a previous
-call to the redef function: nc_redef in C (see nc_redef) or NF_REDEF
-in Fortran (see NF_REDEF). If you create all necessary dimensions,
-variables, and attributes before writing data, and avoid later
-additions and renamings of netCDF components that require more space
-in the header part of the file, you avoid the cost associated with
-later changing the header.
+incurred when the enddef function is called: nc_enddef() in C,
+NF_ENDDEF() in Fortran, after a previous call to the redef function:
+nc_redef() in C or NF_REDEF() in Fortran. If you create all necessary
+dimensions, variables, and attributes before writing data, and avoid
+later additions and renamings of netCDF components that require more
+space in the header part of the file, you avoid the cost associated
+with later changing the header.
Alternatively, you can use an alternative version of the enddef
function with two underbar characters instead of one to explicitly
reserve extra space in the file header when the file is created: in C
-nc__enddef (see nc__enddef), in Fortran NF__ENDDEF (see NF__ENDDEF),
-after a previous call to the redef function. This avoids the expense
-of moving all the data later by reserving enough extra space in the
-header to accommodate anticipated changes, such as the addition of new
-attributes or the extension of existing string attributes to hold
-longer strings.
+nc__enddef(), in Fortran NF__ENDDEF(), after a previous call to the
+redef function. This avoids the expense of moving all the data later
+by reserving enough extra space in the header to accommodate
+anticipated changes, such as the addition of new attributes or the
+extension of existing string attributes to hold longer strings.
When the size of the header is changed, data in the file is moved, and
the location of data values in the file changes. If another program is
@@ -1352,13 +1364,13 @@ this section applies only to systems with LFS.
The original binary format of netCDF (classic format) limits the size
of data files by using a signed 32-bit offset within its internal
structure. Files larger than 2 GiB can be created, with certain
-limitations. See Classic Limitations.
+limitations. See \ref limitations.
In version 3.6.0, netCDF included its first-ever variant of the
underlying data format. The new format introduced in 3.6.0 uses 64-bit
file offsets in place of the 32-bit offsets. There are still some
limits on the sizes of variables, but the new format can create very
-large datasets. See 64 bit Offset Limitations.
+large datasets. See \ref netcdf_64bit_offset_format.
NetCDF-4 variables and files can be any size supported by the
underlying file system.
@@ -1492,8 +1504,8 @@ dataset while other processes read it.
Data reads and writes are no more atomic than calls to stdio fread()
and fwrite(). An nc_sync/NF_SYNC call is analogous to the fflush call
in the C standard I/O library, writing unwritten buffered data so
-other processes can read it; The C function nc_sync (see nc_sync), or
-the Fortran function NF_SYNC (see NF_SYNC), also brings header changes
+other processes can read it; The C function nc_sync(), or
+the Fortran function NF_SYNC(), also brings header changes
up-to-date (for example, changes to attribute values). Opening the
file with the NC_SHARE (in C) or the NF_SHARE (in Fortran) is
analogous to setting a stdio stream to be unbuffered with the _IONBF
@@ -1607,7 +1619,7 @@ script. Currently they are set to 10 and 64 MB.)
To change the default chunk cache size, use the set_chunk_cache
function before opening the file with nc_set_chunk_cache(). Fortran 77
-programmers see NF_SET_CHUNK_CACHE). Fortran 90 programmers use the
+programmers see NF_SET_CHUNK_CACHE()). Fortran 90 programmers use the
optional cache_size, cache_nelems, and cache_preemption parameters to
nf90_open/nf90_create to change the chunk size before opening the
file.
@@ -1615,11 +1627,17 @@ file.
To change the per-variable cache size, use the set_var_chunk_cache
function at any time on an open file. C programmers see
nc_set_var_chunk_cache(), Fortran 77 programmers see
-NF_SET_VAR_CHUNK_CACHE, ).
+NF_SET_VAR_CHUNK_CACHE().
\section default_chunking_4_1 The Default Chunking Scheme
-Unfortunately, there are no general-purpose chunking defaults that are optimal for all uses. Different patterns of access lead to different chunk shapes and sizes for optimum access. Optimizing for a single specific pattern of access can degrade performance for other access patterns. By creating or rewriting datasets using appropriate chunking, it is sometimes possible to support efficient access for multiple patterns of access.
+Unfortunately, there are no general-purpose chunking defaults that are
+optimal for all uses. Different patterns of access lead to different
+chunk shapes and sizes for optimum access. Optimizing for a single
+specific pattern of access can degrade performance for other access
+patterns. By creating or rewriting datasets using appropriate
+chunking, it is sometimes possible to support efficient access for
+multiple patterns of access.
If you don't know or can't anticipate what access patterns will be most common, or you want to store a variable in a way that will support reasonable access along any of its dimensions, you can use the library's default chunking strategy.
diff --git a/libsrc/ncx.m4 b/libsrc/ncx.m4
index 319cdb3e0..f28aa9a43 100644
--- a/libsrc/ncx.m4
+++ b/libsrc/ncx.m4
@@ -16,11 +16,14 @@ dnl
#endif
dnl
-dnl If the m4 macro "ERANGE_FILL" is defined, the I/O to data elements
-dnl that cause NC_ERANGE will be filled with the NC default fill values.
+dnl If "ERANGE_FILL" is defined, the data elements that cause NC_ERANGE will
+dnl be filled with the NC default fill values.
dnl
-define(`SKIP_LOOP', `ifdef(`ERANGE_FILL', `$1++; $2++; continue;')')
+define(`SKIP_LOOP', `
+#ifdef ERANGE_FILL
+ $1++; $2++; continue;
+#endif')
dnl
dnl The command-line m4 macro "PNETCDF" is to differentiate PnetCDF and netCDF
@@ -79,7 +82,9 @@ ifdef(`PNETCDF',,`define(`DEBUG_ASSIGN_ERROR',`$1 = $2;')')
dnl
dnl *fillp is the fill value in internal representation
dnl
-define(`FillValue', `ifdef(`ERANGE_FILL', `ifelse(
+define(`FillValue', `
+#ifdef ERANGE_FILL
+ ifelse(
`$1', `schar', `if (fillp != NULL) memcpy($2, fillp, 1);',dnl
`$1', `uchar', `if (fillp != NULL) memcpy($2, fillp, 1);',dnl
`$1', `short', `if (fillp != NULL) memcpy($2, fillp, 2);',dnl
@@ -93,7 +98,8 @@ define(`FillValue', `ifdef(`ERANGE_FILL', `ifelse(
`$1', `longlong', `if (fillp != NULL) memcpy($2, fillp, 8);',dnl
`$1', `int64', `if (fillp != NULL) memcpy($2, fillp, 8);',dnl
`$1', `ulonglong', `if (fillp != NULL) memcpy($2, fillp, 8);',dnl
-`$1', `uint64', `if (fillp != NULL) memcpy($2, fillp, 8);')')')dnl
+`$1', `uint64', `if (fillp != NULL) memcpy($2, fillp, 8);')
+#endif')dnl
dnl
dnl
@@ -623,7 +629,9 @@ dnl For GET APIs boundary check
dnl
define(`GETF_CheckBND',
`if (xx > (double)Upcase($1)_MAX || xx < Dmin($1)) {
- ifdef(`ERANGE_FILL',`*ip = FillDefaultValue($1);')
+#ifdef ERANGE_FILL
+ *ip = FillDefaultValue($1);
+#endif
DEBUG_RETURN_ERROR(NC_ERANGE)
}
*ip = ($1)xx;')dnl
@@ -637,7 +645,9 @@ define(`GETF_CheckBND2',
`if (xx == Upcase($1)_MAX) *ip = Upcase($1)_MAX;
else if (xx == Upcase($1)_MIN) *ip = Upcase($1)_MIN;')
else if (xx > (double)Upcase($1)_MAX || xx < Dmin($1)) {
- ifdef(`ERANGE_FILL',`*ip = FillDefaultValue($1);')
+#ifdef ERANGE_FILL
+ *ip = FillDefaultValue($1);
+#endif
DEBUG_RETURN_ERROR(NC_ERANGE)
}
else *ip = ($1)xx;')
@@ -691,19 +701,23 @@ ifelse(`$3', `1',
if (xx > Imax($2)'`ifelse(index(`$1',`u'), 0, ,
index(`$2',`u'), 0, ,
` || xx < Imin($2)')'`) {
-ifdef(`ERANGE_FILL',`dnl
+#ifdef ERANGE_FILL
*ip = FillDefaultValue($2);
- DEBUG_RETURN_ERROR(NC_ERANGE)',`
- DEBUG_ASSIGN_ERROR(err, NC_ERANGE)')
+ DEBUG_RETURN_ERROR(NC_ERANGE)
+#else
+ DEBUG_ASSIGN_ERROR(err, NC_ERANGE)
+#endif
}'
`#'endif
`ifelse(index(`$1',`u'), 0, , index(`$2',`u'), 0,`dnl
if (xx < 0) {
-ifdef(`ERANGE_FILL',`dnl
+#ifdef ERANGE_FILL
*ip = FillDefaultValue($2);
- DEBUG_RETURN_ERROR(NC_ERANGE)',`
- DEBUG_ASSIGN_ERROR(err, NC_ERANGE)') /* because ip is unsigned */
+ DEBUG_RETURN_ERROR(NC_ERANGE)
+#else
+ DEBUG_ASSIGN_ERROR(err, NC_ERANGE) /* because ip is unsigned */
+#endif
}')'dnl
*ip = ($2) xx;
@@ -728,11 +742,17 @@ APIPrefix`x_put_'NC_TYPE($1)_$2(void *xp, const $2 *ip, void *fillp)
ifelse(`$2', `double', `if (*ip > Xmax($1) || *ip < DXmin($1)) {
FillValue($1, &xx)
DEBUG_ASSIGN_ERROR(err, NC_ERANGE)
- } ifdef(`ERANGE_FILL',`else')',
+ }
+#ifdef ERANGE_FILL
+ else
+#endif',
`$2', `float', `if (*ip > (double)Xmax($1) || *ip < FXmin($1)) {
FillValue($1, &xx)
DEBUG_ASSIGN_ERROR(err, NC_ERANGE)
- } ifdef(`ERANGE_FILL',`else')')
+ }
+#ifdef ERANGE_FILL
+ else
+#endif')
xx = (ix_$1)*ip;
put_ix_$1(xp, &xx);
@@ -763,13 +783,19 @@ ifelse(`$3', `1',
` || *ip < Xmin($1)')'`) {
FillValue($1, &xx)
DEBUG_ASSIGN_ERROR(err, NC_ERANGE)
- } ifdef(`ERANGE_FILL',`else')
+ }
+#ifdef ERANGE_FILL
+ else
+#endif
`#'endif
ifelse(index(`$1',`u'), 0, `ifelse(index(`$2',`u'), 0, ,`dnl
if (*ip < 0) {
FillValue($1, &xx)
DEBUG_ASSIGN_ERROR(err, NC_ERANGE) /* because xp is unsigned */
- } ifdef(`ERANGE_FILL',`else')
+ }
+#ifdef ERANGE_FILL
+ else
+#endif
')')dnl
xx = (ix_$1)*ip;
@@ -937,13 +963,15 @@ APIPrefix`x_put_'NC_TYPE(ushort)_schar(void *xp, const schar *ip, void *fillp)
int err=NC_NOERR;
uchar *cp;
if (*ip < 0) {
-ifdef(`ERANGE_FILL', `dnl
+#ifdef ERANGE_FILL
if (fillp != NULL) memcpy(xp, fillp, 2);
#ifndef WORDS_BIGENDIAN
swapn2b(xp, xp, 1);
#endif
- DEBUG_RETURN_ERROR(NC_ERANGE)',`dnl
- DEBUG_ASSIGN_ERROR(err, NC_ERANGE)')
+ DEBUG_RETURN_ERROR(NC_ERANGE)
+#else
+ DEBUG_ASSIGN_ERROR(err, NC_ERANGE)
+#endif
}
cp = (uchar *) xp;
@@ -1146,11 +1174,12 @@ APIPrefix`x_put_'NC_TYPE(uint)_schar(void *xp, const schar *ip, void *fillp)
{
uchar *cp;
if (*ip < 0) {
-ifdef(`ERANGE_FILL', `dnl
+#ifdef ERANGE_FILL
if (fillp != NULL) memcpy(xp, fillp, 4);
#ifndef WORDS_BIGENDIAN
swapn4b(xp, xp, 1);
-#endif')
+#endif
+#endif
DEBUG_RETURN_ERROR(NC_ERANGE)
}
@@ -1628,10 +1657,14 @@ APIPrefix`x_put_'NC_TYPE(float)_float(void *xp, const float *ip, void *fillp)
int err=NC_NOERR;
float *_ip=ip;
#ifdef NO_IEEE_FLOAT
- ifdef(`ERANGE_FILL',`float tmp;')
+#ifdef ERANGE_FILL
+ float tmp;
+#endif
if (*ip > X_FLOAT_MAX || *ip < X_FLOAT_MIN) {
FillValue(float, &tmp)
- ifdef(`ERANGE_FILL',`_ip = &tmp;')
+#ifdef ERANGE_FILL
+ _ip = &tmp;
+#endif
DEBUG_ASSIGN_ERROR(err, NC_ERANGE)
}
#endif
@@ -1947,11 +1980,19 @@ APIPrefix`x_get_'NC_TYPE(double)_float(const void *xp, float *ip)
double xx;
get_ix_double(xp, &xx);
if (xx > FLT_MAX) {
- ifdef(`ERANGE_FILL', `*ip = NC_FILL_FLOAT;', `*ip = FLT_MAX;')
+#ifdef ERANGE_FILL
+ *ip = NC_FILL_FLOAT;
+#else
+ *ip = FLT_MAX;
+#endif
DEBUG_RETURN_ERROR(NC_ERANGE)
}
if (xx < (-FLT_MAX)) {
- ifdef(`ERANGE_FILL', `*ip = NC_FILL_FLOAT;', `*ip = (-FLT_MAX);')
+#ifdef ERANGE_FILL
+ *ip = NC_FILL_FLOAT;
+#else
+ *ip = (-FLT_MAX);
+#endif
DEBUG_RETURN_ERROR(NC_ERANGE)
}
*ip = (float) xx;
@@ -1987,7 +2028,10 @@ APIPrefix`x_put_'NC_TYPE(double)_float(void *xp, const float *ip, void *fillp)
if ((double)(*ip) > X_DOUBLE_MAX || (double)(*ip) < X_DOUBLE_MIN) {
FillValue(double, &xx)
DEBUG_ASSIGN_ERROR(err, NC_ERANGE)
- } ifdef(`ERANGE_FILL',`else')
+ }
+#ifdef ERANGE_FILL
+ else
+#endif
#endif
xx = (double) *ip;
@@ -2002,10 +2046,14 @@ APIPrefix`x_put_'NC_TYPE(double)_double(void *xp, const double *ip, void *fillp)
int err=NC_NOERR;
double *_ip = ip;
#ifdef NO_IEEE_FLOAT
- ifdef(`ERANGE_FILL',`double tmp=NC_FILL_DOUBLE;')
+#ifdef ERANGE_FILL
+ double tmp=NC_FILL_DOUBLE;
+#endif
if (*ip > X_DOUBLE_MAX || *ip < X_DOUBLE_MIN) {
FillValue(double, &tmp)
- ifdef(`ERANGE_FILL',`_ip = &tmp;')
+#ifdef ERANGE_FILL
+ _ip = &tmp;
+#endif
DEBUG_ASSIGN_ERROR(err, NC_ERANGE)
}
#endif
@@ -2468,7 +2516,9 @@ APIPrefix`x_getn_'NC_TYPE($1)_$2(const void **xpp, IntType nelems, $2 *tp)
ifelse(index(`$1',`u'), 0, ,
index(`$2',`u'), 0, `
if (*xp < 0) {
- ifdef(`ERANGE_FILL',`*tp = FillDefaultValue($2);')
+#ifdef ERANGE_FILL
+ *tp = FillDefaultValue($2);
+#endif
DEBUG_ASSIGN_ERROR(status, NC_ERANGE) /* because tp is unsigned */
SKIP_LOOP(xp, tp)
}')dnl
@@ -2500,7 +2550,9 @@ APIPrefix`x_pad_getn_'NC_TYPE($1)_$2(const void **xpp, IntType nelems, $2 *tp)
ifelse(index(`$1',`u'), 0, ,
index(`$2',`u'), 0, `
if (*xp < 0) {
- ifdef(`ERANGE_FILL', `*tp = FillDefaultValue($2);')
+#ifdef ERANGE_FILL
+ *tp = FillDefaultValue($2);
+#endif
DEBUG_ASSIGN_ERROR(status, NC_ERANGE) /* because tp is unsigned */
SKIP_LOOP(xp, tp)
}')dnl
diff --git a/libsrc/putget.m4 b/libsrc/putget.m4
index bf37fb082..70987ba25 100644
--- a/libsrc/putget.m4
+++ b/libsrc/putget.m4
@@ -704,15 +704,17 @@ putNCvx_$1_$2(NC3_INFO* ncp, const NC_var *varp,
size_t remaining = varp->xsz * nelems;
int status = NC_NOERR;
void *xp;
- void *fillp;
+ void *fillp=NULL;
if(nelems == 0)
return NC_NOERR;
assert(value != NULL);
+#ifdef ERANGE_FILL
fillp = malloc(varp->xsz);
- status = NC3_inq_var_fill(varp, fillp);
+ status = NC3_inq_var_fill(varp, fillp);
+#endif
for(;;)
{
@@ -741,7 +743,9 @@ putNCvx_$1_$2(NC3_INFO* ncp, const NC_var *varp,
value += nput;
}
+#ifdef ERANGE_FILL
free(fillp);
+#endif
return status;
}