[netCDF #BOE-466631]: bug ?

> Hello,
>
> I realize there is sometihng really weird with my file. I get this
> with both 4.0 and 4.0.1
>
> I'm attachnig the file.
>
> When I write the attribute "units" on the time axis, I DO get len 19
>
> The nc_inq_Att does tell it is of len 19.
>
> But somehow if I do not set my returned value [19] to '\0' it keeps
> going.
>
> Is that an expected thing ?
>
> When I do a "more" on the attached binary. It noticed that the "units"
> attribute has a '\C' before the '\0'
>
> Where is it coming from, I have no idea, again, my strlen() and the
> nc_put both have the right length.
>
> The nc_inq after writing comes back with the right length
>
> Am I missing something obvious ?
>
> Here's my code reading the qattribute
>
> and the "bad" file.
>
> C>
> static int cdattget(PyCdunifFileObject *file, int varid, const char*
> name, void* value){
> int err,tmp;
> nc_type dtype;
> int t_len;
>
> if (file->filetype==CuNetcdf) {
> err = ncattinq(file->id, varid, name, &dtype, &t_len);
> printf("%s inq told us: len: %i\n",name, t_len);
> if (err==-1)
> return -1;
> tmp = nc_get_att_any(file->id, varid, name, dtype, value);
> printf("name: %s, type: %i, CHAR Type: %i\n",name,dtype,NC_CHAR);
> if (dtype == NC_CHAR) {
> printf("%s : ncget gave us: ---%s---, %i\n",name, (char *)value,
> strlen(value));
> ((char *)value)[t_len]='\0';
> }
> return tmp;
> }
> else
> return cuattget(file->id,varid,name,value);
> }
>
>
>
>

Howdy Charles!

I think you have forgotten that the strlen function does not include the null
byte at the end of the string. If you have a string of 19 characters, and write
that as an attribute, then the null byte (the 20th byte) will not be written in
the attribute. When you read in the attribute, you must supply it yourself.

Alternatively, write strlen() + 1 bytes, and the null byte will be written to
the attribute.

Good luck!

Ed

Ticket Details
===================
Ticket ID: BOE-466631
Department: Support netCDF
Priority: Normal
Status: Closed