|
|
 |
 |
 |
 |
Fortran Programming Language
|
 |
 |
 |
 |
|
|
|
|
<nul> Characters in Fortran 77
Dear all:
I am working with a large scientific parallel code which uses unit 7
for formatted
output. However, at some point the code writes binary <nul> charachters
to unit 7 which is supposed to contain only ascii data.
The error is hard to debug since some debugging output to
unit 7 seems to be missing. Instead there are these <nul> characters.
The code has hundred's of WRITE statements to unit 7.
I am running the code on a Cray XD1 system with Portland pgf77
compiler using the version mpich-pgi601.
Please give me a hint how to find the IO command which produces
the <nul> characters.
Best regards,
Andreas
On 10 apr, 11:23, Andreas Ernst <aer@ix.urz.uni-heidelberg.de>
wrote:
> Dear all: > I am working with a large scientific parallel code which uses unit 7
> for formatted
> output. However, at some point the code writes binary <nul> charachters
> to unit 7 which is supposed to contain only ascii data.
> The error is hard to debug since some debugging output to
> unit 7 seems to be missing. Instead there are these <nul> characters.
> The code has hundred's of WRITE statements to unit 7.
> I am running the code on a Cray XD1 system with Portland pgf77
> compiler using the version mpich-pgi601.
> Please give me a hint how to find the IO command which produces
> the <nul> characters.
> Best regards,
> Andreas
character*10 cc
cc = char(0)
will cause cc to contain a single nul character and 9 spaces.
I suppose you could get them via Z or B formats too.
However, the most likely cause is a character variable that
is not (completely) defined (has not received a value).
For instance:
character*10 cc
write(*,*) cc
is likely to produce a set of non-printable characters
among which nuls.
Try and identify where all character variables are set.
(There may be a compiler option that helps track uninitialised
variables - I do not know the pg compiler though)
Regards,
Arjen
Hi, Arjen:
Thanks for the help. There is only one line with as much as 433 <nul>
characters.
Andreas
> Hm, nul characters can be generated in a few ways: > character*10 cc
> cc = char(0)
> will cause cc to contain a single nul character and 9 spaces.
> I suppose you could get them via Z or B formats too.
> However, the most likely cause is a character variable that
> is not (completely) defined (has not received a value).
> For instance:
> character*10 cc
> write(*,*) cc
> is likely to produce a set of non-printable characters
> among which nuls.
> Try and identify where all character variables are set.
> (There may be a compiler option that helps track uninitialised
> variables - I do not know the pg compiler though)
> Regards,
> Arjen
"Andreas Ernst" <aer @ix.urz.uni-heidelberg.de> wrote in message
> The code has hundred's of WRITE statements to unit 7.
Is the value 7 hard-wired? If not, you could try divide and conquer: set the
unit value to 7 and then change it to another value part way through
execution. Your nulls will be in one of the files. Repeat the process until
you've localised the offending write statement.
If this can't be done, you can rewind the file part way through execution.
Now the nulls are there or are not there. You can narrow it down as above.
Regards,
Mike Metcalf
Andreas Ernst wrote: > Dear all: > I am working with a large scientific parallel code which uses unit 7 for
> formatted
> output. However, at some point the code writes binary <nul> charachters
> to unit 7 which is supposed to contain only ascii data.
> The error is hard to debug since some debugging output to
> unit 7 seems to be missing. Instead there are these <nul> characters.
> The code has hundred's of WRITE statements to unit 7.
> I am running the code on a Cray XD1 system with Portland pgf77
> compiler using the version mpich-pgi601.
> Please give me a hint how to find the IO command which produces
> the <nul> characters.
> Best regards,
> Andreas
errors. Try turning on all of the run-time (as well as compile-time)
error checking you can. Subscript bounds checking, argument mismatch
checking, and use of undefined variables are the most likely culprits.
Can you try the program with a different compiler? That usually
doesn't fix the problem, but it can help fix the blame.
Dick Hendrickson
In article
<pbMSh.31649$VU4.5@bgtnsc05-news.ops.worldnet.att.net>,
Dick Hendrickson <dick.hendrick@att.net> wrote:
> The universal answer for weird output is to check for program > errors. Try turning on all of the run-time (as well as compile-time) > error checking you can. Subscript bounds checking, argument mismatch > checking, and use of undefined variables are the most likely culprits. > Can you try the program with a different compiler? That usually
> doesn't fix the problem, but it can help fix the blame.
I think the standard gives some leeway about unspecified characters,
and some compilers pad with spaces (like an assignment), others pad
with nuls, and others pad with whatever happens to be in those bytes
at load time.
$.02 -Ron Shepard
"Ron Shepard" <ron-shep @NOSPAM.comcast.net> wrote in message
> Some compilers do oddball things with character data statements too.
> I think the standard gives some leeway about unspecified characters,
> and some compilers pad with spaces (like an assignment), others pad
> with nuls, and others pad with whatever happens to be in those bytes
> at load time.
makes it very clear that blank padding occurs. I see no leeway whatsoever.
Regards,
Mike Metcalf
In article <ALNSh.10056$eC.3350@trndny03>,
"Michael Metcalf" <michaelmetc@compuserve.com> wrote:
> "Ron Shepard" <ron-shep @NOSPAM.comcast.net> wrote in message > news:ron-shepard-0548F1.09514910042007@comcast.dca.giganews.com... > > Some compilers do oddball things with character data statements too.
> > I think the standard gives some leeway about unspecified characters,
> > and some compilers pad with spaces (like an assignment), others pad
> > with nuls, and others pad with whatever happens to be in those bytes
> > at load time.
> Well, we're talking about Fortran 77 here, and Section 9.4 of that standard
> makes it very clear that blank padding occurs. I see no leeway whatsoever.
problems in the past. In fact, I still have old output files from
over 10 years ago that have nuls in them because of this. My
workaround was to replace data statement initialization with
assignments.
$.02 -Ron Shepard
Hello,
Ron Shepard wrote:
<snip>
> I don't remember the details, but I do know that this has caused
> problems in the past. In fact, I still have old output files from
> over 10 years ago that have nuls in them because of this. My
> workaround was to replace data statement initialization with
> assignments.
I don't know which compiler you were using, but in f77, 9.4,
2nd paragraph is very clear. Character items are blank padded.
The one place I've gotten <nul>s in characters is from the output
of date_and_time(), that was required not to be a normal assignment.
I regarded that at the time as an anomaly, and IIRC it's been
changed in the standard since that time.
--
Dan Nagle
Purple Sage Computing Solutions, Inc.
Dan Nagle <danna @verizon.net> wrote: > Hello, > Ron Shepard wrote:
> <snip>
> > I don't remember the details, but I do know that this has caused
> > problems in the past. In fact, I still have old output files from
> > over 10 years ago that have nuls in them because of this. My
> > workaround was to replace data statement initialization with
> > assignments.
> I don't know which compiler you were using, but in f77, 9.4,
> 2nd paragraph is very clear. Character items are blank padded.
character c*12
data c(1:5)/'Nagle'/
or some such thing. Then you've just got classic undefined stuff for the
rest.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
Hello,
Richard Maine wrote: > Dan Nagle <danna @verizon.net> wrote:
> Possibly if only a substring was initialized? Such as > character c*12
> data c(1:5)/'Nagle'/
> or some such thing. Then you've just got classic undefined stuff for the
> rest.
It doesn't say how it got to be an entity. :-)
Further on, the entity could be a variable, array element
or substring.
And it's true of assignment as well, so it may have been
thought to be expected.
--
Dan Nagle
Purple Sage Computing Solutions, Inc.
The most common source of nul characters in output in an error
situation is that of un-ititialized variables. This was said earlier.
A formatted statement can output nuls if A2 is used to output an
integer variable whose value is 0.
Or an A1 for a byte whose bits are all zero.
You said you had a case of 433 nuls, so somewhere you have an odd
byte.
First look for a statement that writes 433 bytes in total.
If you cannot find one, look for atstement that is frequently executed
in a loop and writes a lot less than this number. But if the output
was formatted you would have 0Dh 0Ah somehere among the nuls.
So be SURE that you really have ininterrupted nuls.
Another trick is to include new lines of output in strategic places,
say, with the nearest lable included like "XXXX 123 XXX" and check the
output to narrow down where the error is happening.
In article <nqTSh.12270$op4.9449@trnddc08>,
Dan Nagle <dna@erols.com> wrote:
>Hello, >Richard Maine wrote:
>> Dan Nagle <danna@verizon.net> wrote:
><snip>
>> Possibly if only a substring was initialized? Such as
>> character c*12
>> data c(1:5)/'Nagle'/
>> or some such thing. Then you've just got classic undefined stuff for the
>> rest.
>Yea, could be. The wording speaks of an entity of type character.
>It doesn't say how it got to be an entity. :-)
CHARACTER STUFF(2)*10
DATA STUFF(1)/'foobar'/, STUFF(2)(1:6)/'foobar'/
DO j=1,2
PRINT "(10I4)", (ICHAR(STUFF(j)(i:i)),i=1,10)
PRINT "(10A4)", ( STUFF(j)(i:i) ,i=1,10)
END DO
END
g77, g95, Sun f95, Compaq f95 and NAG f95 all gave the same output:
102 111 111 98 97 114 32 32 32 32
f o o b a r
102 111 111 98 97 114 0 0 0 0
f o o b a r
-- John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail john.har@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045
Thank you for all the replies!
I found another astonishing fact about this bug: It seems that the
fort.7 file is written for some time, then it is deleted and created
new. Then some output is written in the file and, after a short time,
the <nul> characters.
The beginning of the fort.7 output file is missing as if it has been deleted.
When I use
tail -f fort.7
there comes the message:
tail: file truncated
I have no idea what is going on here.
Andreas
The most common source of nul characters in output in an error
> situation is that of un-ititialized variables. This was said earlier. > I will check that!
> integer variable whose value is 0. > Or an A1 for a byte whose bits are all zero. > You said you had a case of 433 nuls, so somewhere you have an odd
> byte.
> From time to time, the number of <nul>'s changes!
> If you cannot find one, look for atstement that is frequently executed > in a loop and writes a lot less than this number. But if the output > was formatted you would have 0Dh 0Ah somehere among the nuls. > So be SURE that you really have ininterrupted nuls. > Another trick is to include new lines of output in strategic places,
> say, with the nearest lable included like "XXXX 123 XXX" and check the
> output to narrow down where the error is happening.
(someone wrote)
(snip)
> A formatted statement can output nuls if A2 is used to output an
> integer variable whose value is 0.
> Or an A1 for a byte whose bits are all zero.
Writing non-character data with any A format could easily generate
nulls. This is a Fortran 66 feature still supported by many
compilers. It seems that gfortran does it by default, g95
requires the -fsloppy-strings compiler option.
I am now running a macro processor written in Fortran sometime
around 1975 which, as usual for Fortran 66, stores its character
data into integer variables. g95 nicely tells you how to fix
the problem when it detects reading an INTEGER array in 80A1 format.
-- glen
Glen wrote:
> Writing non-character data with any A format could easily generate
> nulls. This is a Fortran 66 feature still supported by many
> compilers. It seems that gfortran does it by default, g95
> requires the -fsloppy-strings compiler option.
This reads as if any formatted output character (using A1) below #20
or above #7F would produce a nul character.
This is not so in my experience, Especially since the Spanish and
French I spoke since 1961 has to use the upper ascii table for MS
multilingual set-ups, and not even happened with F66 which I used
after Fortran IV till about 1978.
I truly think I would have noticed as a "Fortran man" with IBM or
Shell.
I don't think (remember) it even happened with FORTRAN IV either.
What DID happen is that certain characters would ACT as if they were
nuls and stop an output.
This is not quite the same thing.
A quick example: If you hit an escape key on input to a read formatted
console input, this stops the input on F77 and earlier. It was things
like like that made me have to write a TUI to capture and edit other
language texts on console I/O.
Terence wrote:
>>Writing non-character data with any A format could easily generate
>>nulls. This is a Fortran 66 feature still supported by many
>>compilers. It seems that gfortran does it by default, g95
>>requires the -fsloppy-strings compiler option.
> This reads as if any formatted output character (using A1) below #20
> or above #7F would produce a nul character.
No, but it is pretty easy. I am not so sure now about little
endian machines, but for big endian A1 uses the high order
byte, which is easily zero.
-- glen
On 11 Apr 2007 04:36:32 -0700, Terence wrote:
> Glen wrote:
>> Writing non-character data with any A format could easily generate
>> nulls. This is a Fortran 66 feature still supported by many
>> compilers. It seems that gfortran does it by default, g95
>> requires the -fsloppy-strings compiler option.
> This reads as if any formatted output character (using A1) below #20
> or above #7F would produce a nul character.
I don't see that it says that at all. Consider the following:
integer x
x = 175
write "(a4)", x
This is likely to produce nulls, since the upper bytes of x are all zero.
> This is not so in my experience, Especially since the Spanish and
> French I spoke since 1961 has to use the upper ascii table for MS
> multilingual set-ups, and not even happened with F66 which I used
> after Fortran IV till about 1978.
How does that affect the code example above? One of the generated
characters is surely non-null, but the other three are null.
Even if you write with A1 format, the claim still holds. After all, it
was not claimed that nulls would always be produced -- only that they
could easily be produced (depending on the value of the variable being
written, which could very easily be zero).
> I truly think I would have noticed as a "Fortran man" with IBM or
> Shell.
> I don't think (remember) it even happened with FORTRAN IV either.
> What DID happen is that certain characters would ACT as if they were
> nuls and stop an output.
> This is not quite the same thing.
Nulls are not required to stop output. If they did for the particular
compiler in question, we probably wouldn't be having this discussion in
the first place.
> A quick example: If you hit an escape key on input to a read formatted
> console input, this stops the input on F77 and earlier. It was things
> like like that made me have to write a TUI to capture and edit other
> language texts on console I/O.
Nothing was claimed about input. The discussion was about nulls in
output.
--
Dave Seaman
Oral Arguments in Mumia Abu-Jamal Case to be heard May 17
U.S. Court of Appeals, Third Circuit
<http://mumia2000.org/>
In a previous article, "Terence" <tbwri@cantv.net> wrote:
>Glen wrote: >> Writing non-character data with any A format could easily generate >> nulls. This is a Fortran 66 feature still supported by many >> compilers. It seems that gfortran does it by default, g95 >> requires the -fsloppy-strings compiler option. >This reads as if any formatted output character (using A1) below #20
>or above #7F would produce a nul character.
>This is not so in my experience, Especially since the Spanish and
>French I spoke since 1961 has to use the upper ascii table for MS
>multilingual set-ups, and not even happened with F66 which I used
>after Fortran IV till about 1978.
>I truly think I would have noticed as a "Fortran man" with IBM or
>Shell.
>I don't think (remember) it even happened with FORTRAN IV either.
>What DID happen is that certain characters would ACT as if they were
>nuls and stop an output.
>This is not quite the same thing.
What was meant (AFAICS) was e.g.
afloat=0.
write(6,'(a4)')afloat
a compact way of writing numerical data (e.g. to cards).
Chris
On Apr 11, 7:07 am, Dave Seaman <dsea@no.such.host> wrote:
> On 11 Apr 2007 04:36:32 -0700, Terence wrote: > > Glen wrote:
> >> Writing non-character data with any A format could easily generate
> >> nulls. This is a Fortran 66 feature still supported by many
> >> compilers. It seems that gfortran does it by default, g95
> >> requires the -fsloppy-strings compiler option.
> > This reads as if any formatted output character (using A1) below #20
> > or above #7F would produce a nul character.
> I don't see that it says that at all. Consider the following:
> integer x
> x = 175
> write "(a4)", x
> This is likely to produce nulls, since the upper bytes of x are all zero.
> <snip> > -- > Dave Seaman > Oral Arguments in Mumia Abu-Jamal Case to be heard May 17 > U.S. Court of Appeals, Third Circuit > < http://mumia2000.org/>
In article <t6SdnSh4tfXFCYHbnZ2dnUVZ_uSgn@comcast.com>,
glen herrmannsfeldt <g@ugcs.caltech.edu> wrote:
>Writing non-character data with any A format could easily generate
>nulls. This is a Fortran 66 feature still supported by many
>compilers. It seems that gfortran does it by default, g95
>requires the -fsloppy-strings compiler option.
-- John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail john.har@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045
Two things about the following.
"Terence wrote:"
>>Writing non-character data with any A format could easily generate
>>nulls. This is a Fortran 66 feature still supported by many
>>compilers. It seems that gfortran does it by default, g95
>>requires the -fsloppy-strings compiler option.
> This reads as if any formatted output character (using A1) below #20
> or above #7F would produce a nul character......
1) I did not write the quote attributed to me, but I DID write the
comment under the original quote. This can confuse readers.
2) part of the resulting further confusion of is the meaning of words.
When I use the phrase "non-character" and then specify the valid hex
values of the ascii table considered to be "characters", I thought I
was being pretty clear.
Since I was referring to a format A1, I did not mean (as I had
PREVIOUSLY stated as ANOTHER way of getting nulls using A2), that this
was to generalised to writing a binary value of more than one byte to
a larger string than one byte.
Also, if the original problem involves 433 successive nuls, in normal
circumstances there is probably a single byte involved which will
yield an important clue. The exception is of course a long unitialised
string, which I had ALREADY covered at the outset.
I still rather doubt there being so many nulls in an erronious
formatted output in a report file from a single operation, even though
I can cause it to occur by intent.
Terence <tbwri @cantv.net> wrote: > Two things about the following. > "Terence wrote:"
> >>Writing non-character data with any A format could easily generate
> >>nulls. This is a Fortran 66 feature still supported by many
> >>compilers. It seems that gfortran does it by default, g95
> >>requires the -fsloppy-strings compiler option.
> > This reads as if any formatted output character (using A1) below #20
> > or above #7F would produce a nul character......
> 1) I did not write the quote attributed to me, but I DID write the
> comment under the original quote. This can confuse readers.
wrote:" line. Gary used standard and explicit usenet quoting, which
showed what Glenn said and what you replied. You misquoted his quote,
which is what caused confusion. Yes, when you leave out the "Glen wrote"
line, that does make it harder for someone to tell that Glan wrote it.
> 2) part of the resulting further confusion of is the meaning of words.
> When I use the phrase "non-character" and then specify the valid hex
> values of the ascii table considered to be "characters", I thought I
> was being pretty clear.
I thought you were clear also. So did Gary, as far as I can tell. It
seemed quite clear that your interpretation of Glen's words was not what
Glen wrote.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
Richard Maine wrote:
(snip)
> I thought you were clear also. So did Gary, as far as I can tell. It
> seemed quite clear that your interpretation of Glen's words was not what
> Glen wrote.
Ok, I previously wrote:
>> Writing non-character data with any A format could
>> easily generate nulls.
Some might argue over how likely "could easily" is.
I was at the time thinking about big endian machines, where left
justified A1 format puts the character in the high order byte.
On little endian machines it is the low order byte, so null
characters are somewhat less likely to occur.
I have the source for the Mortran2 processor, a macro processor
for converting Mortran source to Fortran, and written in standard
Fortran 66. It does all its I/O in A1 format.
-- glen
On Apr 11, 8:42?am, Andreas Ernst <aer@ix.urz.uni-heidelberg.de>
wrote:
> Thank you for all the replies! > I found another astonishing fact about this bug: It seems that the
> fort.7 file is written for some time, then it is deleted and created
> new. Then some output is written in the file and, after a short time,
> the <nul> characters.
> The beginning of the fort.7 output file is missing as if it has been deleted.
> When I use
> tail -f fort.7
> there comes the message:
> tail: file truncated
> I have no idea what is going on here.
> Andreas
> The most common source of nul characters in output in an error
> > situation is that of un-ititialized variables. This was said earlier.
> > I will check that!
> A formatted statement can output nuls if A2 is used to output an
> > integer variable whose value is 0.
> > Or an A1 for a byte whose bits are all zero.
> > You said you had a case of 433 nuls, so somewhere you have an odd
> > byte.
> > From time to time, the number of <nul>'s changes!
> First look for a statement that writes 433 bytes in total.
> > If you cannot find one, look for atstement that is frequently executed
> > in a loop and writes a lot less than this number. But if the output
> > was formatted you would have 0Dh 0Ah somehere among the nuls.
> > So be SURE that you really have ininterrupted nuls.
> > Another trick is to include ?new lines of output in strategic places,
> > say, with the nearest lable included like "XXXX 123 XXX" and check the
> > output to narrow down where the error is happening.- Hide quoted text -
>
I wonder if the program is trying to write to unit 7 before the new
file has been properly opened. The nulls could correspond to lost
output that never got properly written.
David Flower
|
|
|
|
|
|
Add to del.icio.us |
Digg this |
Stumble it |
Powered by Megasolutions Inc