NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.

To learn about what's going on, see About the Archive Site.

Re: [netcdfgroup] Closing files opened only for reading (C interface - nc_close()?)

In preparing to paste a code snippet, I found that this *only* happens if I
include a string in the file.  Here is a test function that I made, as well
as an example of how I'm calling nc_open and nc_close:
http://pastebin.com/63HbAWSy

If I comment out either method of putting the string in there, the same
thing happens, unless I comment out both methods. Variables, arrays and
groups don't cause the issue.

Here's a raw paste if you don't want to look at pastebin:

// Test function testing strings.
int rv, ncid;
if(rv = nc_create(fname, NC_NETCDF4, &ncid))
goto error; // Error opening file.

char *string = malloc(250);
sprintf(string, "This is a string.");
 nc_put_att_string(ncid, NC_GLOBAL, "string1", 1, &string);
 char *string2 = "This is also a string";
nc_put_att_string(ncid, NC_GLOBAL, "string2", 1, &string2);
 free(string);
nc_close(ncid);
return rv;

/******* nc_open call: ********/
// Open the netCDF file.
if(rv = nc_open(fname, NC_NOWRITE, &ncid))
goto error;

/******* nc_close call: ********/
if(ncid >= 0)
     nc_close(ncid);

Note that I can actually read those strings or variables and attributes
which are arrays of strings just fine. The only thing that causes problems
is the nc_close(ncid) call, which suspends execution/crashes the program if
there's a string in the file for some reason.

Now that I know this, it's not such a horrible thing, since I can just store
those as arrays of chars, but the string type is actually pretty convenient,
so if anyone has suggestions as to how I can make it deal with the fact that
strings exist, please let me know.

      -Paul
  • 2011 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the netcdfgroup archives: