> 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.
The Fortran character set applies only to program text. The contents of
character variables and literal string constants can contain any representable
characters. What you see when you "print" an ASCII NUL depends on where you
are sending the output. To a file, the NUL is preserved. To a TTY, an ASCII
NUL is not a displayable character. Fortran does not omit NULs -- the TTY is
"displaying" an ASCII NUL the way it was intended to be displayed: as nothing.
Larry Baker
US Geological Survey
650-329-5608
baker@xxxxxxxx
On 16 Jan 2014, at 12:28 PM, 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> 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
>
>
> _______________________________________________
> netcdfgroup mailing list
> netcdfgroup@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe, visit:
> http://www.unidata.ucar.edu/mailing_lists/
