Re: [netcdfgroup] reading null string attribute

  • To: Ben Foster <foster@xxxxxxxx>
  • Subject: Re: [netcdfgroup] reading null string attribute
  • From: Dave Allured - NOAA Affiliate <dave.allured@xxxxxxxx>
  • Date: Wed, 15 Jan 2014 16:05:39 -0700
Ben,

> A call to nf_inq_attlen reports the length to be 1024, which
> was the declared character length of the variable that wrote
> the attribute to the file in the first place, not the actual
> length of the attribute on the current file, which is zero.

This is a source of confusion.  The actual length of the attribute in the
current file really is 1024, not zero. What you probably have is a
character attribute containing 1024 null bytes, which is a very different
animal than what we usually mean by the term "null string", as you said, a
zero length string.  Ncdump deliberately does not display trailing null
bytes in attributes.  So the attribute looks like it is a null string, but
it's not.

Also, I am fairly sure that printing a character string containing null
bytes is actually an undefined operation in fortran, according to the
language standards.  However, common fortran compiler behavior is to omit
printing null bytes, but print all other characters.  Once again, this
creates the appearance of a null string in your case, but it's not a null
string.

And the code that you showed really does read all 1024 null bytes into a
length 1024 fortran character string in your program.

I could show how to test whether a fortran character string contains all
null bytes.  But instead, will the attached filter routine suit your needs?
 It is a wrapper for nf_get_att_text, and it is called exactly the same
way.  Its main function is to convert trailing null bytes into trailing
blanks, which are more easily handled with traditional fortran methods.  It
also handles length mismatches gracefully, thereby simplifying string
length management in your code.  I use this routine almost universally when
processing Netcdf attributes in fortran.

With this routine, your strings of null bytes will become indistinguishable
from ordinary blank strings, and your if statement will simplify to:

    if (initial_file==" ") then

--Dave

On Wed, Jan 15, 2014 at 11:00 AM, Ben Foster <foster@xxxxxxxx> wrote:
>
>
> Hi,
>
> I have a number of files with a global file text attribute
> which is sometimes a "null" (zero length) string. An ncdump
> shows the global attribute as:
>
>  :initial_file = "" ;
>
> I am having trouble reading this with the f77 interface,
> or at least I cannot determine if it is a null value or not.
> I write a short serial fortran test code which declares
> local character(len=1024) :: initial_file, and initializes
> it to blanks (I confirm that len_trim(initial_file)=0,
> and it prints all blanks when printed to stdout).
>
> Then a call to nf_get_att_text returns without error. When
> I print it to stdout, it does print a null string (although
> in my original large MPI code it prints 1024 garbage chars),
> but now len_trim(initial_file) is 1024, not zero. I try a
> conditional comparing it to "", but it returns false. So I
> cannot tell if I have read a null string or not.
>
> A call to nf_inq_attlen reports the length to be 1024, which
> was the declared character length of the variable that wrote
> the attribute to the file in the first place, not the actual
> length of the attribute on the current file, which is zero.
>
> Its not convenient to change the attribute on all these files,
> since they go back at least a few years. BTW, I am running this
> on yellowstone. I have attached the small test program, which
> has the full path to the current file.
> Thanks for any advice,
>
> --Ben

Attachment: get_att_text_safe.f
Description: Binary data

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