Prev: GCC/gfortran 4.5.0 release
Next: linking not done
From: Richard Maine on 17 Apr 2010 02:41
<robert.corbett(a)oracle.com> wrote:

> On Apr 16, 7:39 pm, nos...(a)see.signature (Richard Maine) wrote:

> > In more specific support of my claim that such a transcription method is
> > detrimental to portability, when I tried to copy the source code in
> > question from the posting here, it failed to copy in such a way as to
> > correctly interpfret any such transcription method that might
> > theoretically have been intended. Instead, the compiler that I tried
> > reported it as being a nonstandard tab format. Therefore, if this code
> > was standard conforming for some particular implementation (which I
> > doubt), then it did not manage to copy appropriately for the
> > implementations that I have.
>
> Transferring files between file systems that use incompatible
> file formats is always going to be an issue.
....[elided]

Yes, that is all very fine in theory. In practice, though...

1. This one did not "transfer correctly" for me.

2. All this theorizing ignores the fact that the processor in question
does not, in fact, claim to use such a transcription method - at least
not to my knowledge. I do not deny that such a processor could exist in
theory. I know of no examples in practice that claim to support the
transcription method in question, whereby tabs in the source file are
claimed to be standard conforming for that processor. If you know of
any, I'd be interested in hearing of them. I would be even more
interested if you happened to have information that shows that the OP's
processor made such a claim.

3. Short of any such processors being found, I maintain the substance of
the claim that started this subthread, namely "the code appears to use a
tab source form, which, as you correctly note, is neither standard
conforming fixed nor free source form." In particular:

I still maintain that the code "appears" to use a tab source form. I
grant the abstract possibility that the appearance might be incorrect,
but I still claim that is the appearance.

I also claim that tab source form is nonstandard. I grant that a
processor could use a file representation that involved tabs, but then
that would not be a source form. It would be a transcription method.

I finally still maintain that the code presented is nonstandard for all
processors I have heard of, and for the OP's processor in particular. I
grant the abstract possibility that someone could make a processor for
which the file in question was standard conforming. I also suppose that
is probably slightly more interesting than consideration of the number
of angels that could dance on the head of a pin, but only slightly. I
doubt either will be of much help to the OP in writing portable,
standard conforming Fortran for compilers (or "processors") that exist.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: glen herrmannsfeldt on 17 Apr 2010 04:48
robert.corbett(a)oracle.com wrote:

(snip)

> Transferring files between file systems that use incompatible
> file formats is always going to be an issue. I have used
> FORTRAN compilers where every line of a source program had
> to be the same length because the file system stored text as
> fixed-length records.

I did much Fortran programming on such systems.

> Some people now think that
> transferring source files between Windows, Macs, UNIX,
> and UNIX-like operating systems is a bother because of the
> different line terminators. They have no idea how much
> trouble transferring source files used to be. Of course,
> the fact that each machine had its own character set(s)
> made such transfers all the more interesting.

Such as ASCII/EBCDIC translation... One that still comes
up sometimes is that ASCII doesn't have a not sign, and
EBCDIC doesn't have tilde. Some translation tables translate
between those, though there are some other possibilities.

> One advantage of using fixed-length records was that it was
> possible to consider any character that was representable on
> the machine as a member of the FORTRAN processor's
> processor character set.

I do remember using one of those systems from Fortran,
with a NEWLINE character in a character constant.
(Well, as close as you could come to that in Fortran 66.)
EBCDIC has a newline character in addition to CR and LF,
and it could be used for terminal I/O on some systems.

> That was not possible for systems
> that used control characters to designate the end of a line.
> The FORTRAN 77 standard required a FORTRAN processor to allow
> any character in the processor's processor character set to
> appear in a character context. Whatever characters were used
> as line terminators were excluded from the processor
> character set. Typically, a few other characters were also
> excluded from the processor character set, tabs and form
> feeds frequently among them.

I have at times written programs to do bit image graphics
on various printers, which often requires the ability to send
all 256 possible bit combinations in a byte.

But fixed length records have the problem that you don't know
where the record end is. Not quite as bad as losing some bit
combinations, but still it can cause problems.

-- glen
From: robin on 17 Apr 2010 04:55
"JuanPablo-Chile" <jpsegura(a)gmail.com> wrote in message
news:b7a79b86-b8fd-4f5b-b5ea-36bef3ce217e(a)c36g2000yqm.googlegroups.com...
| Hi:
|
| I changed the code as you recommended and now I am geeting the next
| error:
|
| forrtl: severe (64): input conversion error, unit 1, fil C:\.....

As has already been suggested, you need to print the values
after each read statement, so that you can see where the program
got up to.
That way, you can deduce which line of data is a fault,
and can rectify it.


First  |  Prev  | 
Pages: 1 2 3 4 5 6 7
Prev: GCC/gfortran 4.5.0 release
Next: linking not done