Ben,
My mistake. The subroutine I sent handles only a single trailing null. I
failed to read my own documentation before posting. Here is a
straightforward way to check whether a string is all null characters:
character*1024 string
integer i
logical match
match = .true.
do i = 1, len (string)
if (string(i:i) .ne. char (0)) then
match = .false.
exit
end if
end do
I could not think of a way to omit the loop, at least not in fortran 77.
Also, this uses a couple of fortran 90 constructs which should be obvious
how to convert to pure F77, if needed. Those are exit and end do, I think.
HTH.
--Dave
On Wed, Jan 15, 2014 at 4:05 PM, Dave Allured - NOAA Affiliate <
dave.allured@xxxxxxxx> wrote:
> 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
>
>
