Dave,
Yes, this is working, thanks a lot! BTW, my code is f90, its only
that I'm still using the f77 API for netcdf (i.e., call nf_xxx rather
than call nf90_xxx). I need to bite the bullet and update to the f90
interface. Thanks again for the solution! Also thanks to Larry Baker
for commenting.
--Ben
On 01/16/14 13:28, Dave Allured - NOAA Affiliate wrote:
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 <mailto: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
<mailto: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
