This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
>To: address@hidden >From: Paul van Delst <address@hidden> >Subject: Problem with NF90_GET_ATT on an SGI >Organization: CIMSS@NOAA/NCEP/EMC >Keywords: 200302141632.h1EGWK624961 Paul, > I using the netCDF 3.5.0 F90 interface and I've discovered a problem with > using the > NF90_GET_ATT function to retrieve text attributes on an SGI platform. I use a > call like > so: > > NF90_Status = NF90_GET_ATT( NC_FileID, & > NF90_GLOBAL, & > HISTORY_GATTNAME, & > History ) > > where > CHARACTER( * ), PRIVATE, PARAMETER :: HISTORY_GATTNAME = 'history' > > If the declared length of the argument "History" is smaller (say 256 chars) > than the > length of the attribute in the datafile (in my case 286chars), rather than > the attribute > being truncated, memory beyond the declared string is overwritten. The > following is some > output from my debug session where I put a trace on a main program variable > "n" (a loop > index) that was getting clobbered after a call to NF90_GET_ATT: > > (dbx) next > Process 571314 (Combine_SpcCoeff) stopped at [READ_SPCCOEFF_GATTS:896 > ,0x10071898] > 896 NF90_Status = NF90_GET_ATT( NC_FileID, & > (dbx) whatis history > argument character*256 HISTORY > (dbx) next > [4] n changed before [memcpy: line 577]: > old value = 1; > new value = 808464943; > Process 571314 (Combine_SpcCoeff) stopped on watchpoint writing address > 0xffffff4c20 at > [memcpy:577 ,0xda6111c] > Source (of > /xlv41/6.5.17m/work/irix/lib/libc/libc_64_M4/strings/bcopy.s) not > available for Process 571314 > (dbx) next > Process 571314 (Combine_SpcCoeff) stopped at [memcpy:579 ,0xda61124] > Source (of > /xlv41/6.5.17m/work/irix/lib/libc/libc_64_M4/strings/bcopy.s) not > available for Process 571314 > > ...multiple numbers of these... > > (dbx) next > Process 571314 (Combine_SpcCoeff) stopped at [memcpy:614 ,0xda61234] > Source (of > /xlv41/6.5.17m/work/irix/lib/libc/libc_64_M4/strings/bcopy.s) not > available for Process 571314 > (dbx) next > Process 571314 (Combine_SpcCoeff) stopped at [ncx_pad_getn_text:4060 > ,0x10133310] > 4060 *xpp = (void *)((char *)(*xpp) + nelems + rndup); > (dbx) next > Process 571314 (Combine_SpcCoeff) stopped at [ncx_pad_getn_text:4062 > ,0x10133320] > 4062 return ENOERR; > (dbx) next > Process 571314 (Combine_SpcCoeff) stopped at [ncx_pad_getn_text:4060 > ,0x10133324] > 4060 *xpp = (void *)((char *)(*xpp) + nelems + rndup); > (dbx) next > Process 571314 (Combine_SpcCoeff) stopped at [ncx_pad_getn_text:4062 > ,0x10133328] > 4062 return ENOERR; > (dbx) next > Process 571314 (Combine_SpcCoeff) stopped at [ncx_pad_getn_text:4060 > ,0x1013332c] > 4060 *xpp = (void *)((char *)(*xpp) + nelems + rndup); > (dbx) next > Process 571314 (Combine_SpcCoeff) stopped at [ncx_pad_getn_text:4062 > ,0x10133334] > 4062 return ENOERR; > (dbx) next > Process 571314 (Combine_SpcCoeff) stopped at [NF90_GET_ATT_TEXT:76 > ,0x1008cbb0] > 76 end function nf90_get_att_text > > The exact same code (and data file) works fine on an IBM AIX, Sun > Sparcstation, and linux > box - i.e. the too-long attribute is truncated with no side effects. I'm not > sure if this > is a problem on the SGI side (i.e. compiler problem) or the netCDF side > (problem with how > the ncx_pad_getn_text function works). The function ncx_pad_getn_text() is part of the C interface. By the time it gets the character string, there is no information available about the space available for storing the attribute value. I'm afraid the documented warning applies here: ... All elements of the vector of attribute values are returned, so you must provide enough space to hold them. If you don't know how much space to reserve, call NF90_Inquire_Att first to find out the length of the attribute. So the bottom line is that I don't think there is any practical way to fix this problem, given the existing interface. --Russ