|
|
 Up |
|
|
  |
Author: Clive PageClive Page Date: Aug 13, 2008 02:24
Fortran 2003 defines a NEW_LINE intrinsic function for use when writing
stream I/O.
I just noticed that it is defined to only return a single character,
which is decimal 10 in the ASCII set if that exists, which seems
sensible enough. In the past, however, I have used operating systems in
which the newline sequence in text files was a pair of characters,
usually CR LF or LF CR. Perhaps none of these systems exist any more
for practical purposes, but if they do, the definition of NEW_LINE to
return just *one* character seems a bit restrictive. Any comments from
experts?
--
Clive Page
|
| |
|
| | 5 Comments |
|
|
Author: JayBeeJayBee Date: Aug 13, 2008 03:46
On 2008-08-13, Clive Page wrote:
> Fortran 2003 defines a NEW_LINE intrinsic function for use when writing
> stream I/O.
>
> I just noticed that it is defined to only return a single character,
> which is decimal 10 in the ASCII set if that exists, which seems
> sensible enough. In the past, however, I have used operating systems in
> which the newline sequence in text files was a pair of characters,
> usually CR LF or LF CR. Perhaps none of these systems exist any more
> for practical purposes,
Unfortunately, they do exist.
> but if they do, the definition of NEW_LINE to
> return just *one* character seems a bit restrictive. Any comments from
> experts?
|
| Show full article (1.20Kb) |
|
| | no comments |
|
|
Author: nospamnospam Date: Aug 13, 2008 09:55
Clive Page wrote:
> Fortran 2003 defines a NEW_LINE intrinsic function for use when writing
> stream I/O.
>
> I just noticed that it is defined to only return a single character,
> which is decimal 10 in the ASCII set if that exists, which seems
> sensible enough. In the past, however, I have used operating systems in
> which the newline sequence in text files was a pair of characters,
> usually CR LF or LF CR. Perhaps none of these systems exist any more
> for practical purposes, but if they do, the definition of NEW_LINE to
> return just *one* character seems a bit restrictive. Any comments from
> experts?
|
| Show full article (2.29Kb) |
| no comments |
|
|
Author: Clive PageClive Page Date: Aug 14, 2008 01:57
Thanks for that summary, Richard.
>question is instead used internally in Fortran. The run-time library
>takes care of translation between this character and the OS record
>structure as needed. This is very much like C and its derivatives,
>intentionally so.
I hadn't appreciated that C also behaved that way. One of the (few)
attractions of C, it seems to me, is the impression that one is getting
at the bits in memory (or on disc) without any barriers or possibly
misleading translation stages in the way. Of course the operating
system is always in the way, but it doesn't always interfere. That's
one reason why I welcomed the addition of stream I/O in Fortran - in the
unformatted form at least, it gives the programmer access to the bits in
any file. Maybe that's an illusion, but so far I've been taken in, and
most files that I've wanted to read with it have worked as I expected.
>I almost think that the new_line intrinsic has negative value in that it
>doesn't do anything really useful in practice, but misleads people into
>thinking that it does. I seem to recall that I voted against adding the
>intrinsic, but obviously was on the loosing side. Ah well, I have
>certainly lost on far more significant votes than that one.
|
| Show full article (1.37Kb) |
| no comments |
|
|
Author: glen herrmannsfeldtglen herrmannsfeldt Date: Aug 14, 2008 03:49
Clive Page wrote:
(snip)
> I hadn't appreciated that C also behaved that way. One of the (few)
> attractions of C, it seems to me, is the impression that one is getting
> at the bits in memory (or on disc) without any barriers or possibly
> misleading translation stages in the way. Of course the operating
> system is always in the way, but it doesn't always interfere. That's
> one reason why I welcomed the addition of stream I/O in Fortran - in the
> unformatted form at least, it gives the programmer access to the bits in
> any file. Maybe that's an illusion, but so far I've been taken in, and
> most files that I've wanted to read with it have worked as I expected.
C has text mode and binary mode. In text mode, '\n' (a single character)
is translated to/from the OS dependent line end marker. In binary mode,
such translation is not done. Because of the possible translation,
there are restrictions on the use of fseek() and ftell() when used
with text mode files. Other than fseek() to the beginning or end
of a file, only fseek() to positions previously returned by ftell()
is allowed for text files. The default for fopen() is for text
mode unless a 'b' is included in the second argument.
|
| Show full article (1.23Kb) |
| no comments |
|
|
|
|
|
Author: Ron ShepardRon Shepard Date: Aug 14, 2008 08:12
In article page.demo.co.uk>,
Clive Page wrote:
> I hadn't appreciated that C also behaved that way. One of the (few)
> attractions of C, it seems to me, is the impression that one is getting
> at the bits in memory (or on disc) without any barriers or possibly
> misleading translation stages in the way.
If you think about it, it really is not practical for a portable
language to return exactly what is in the file. Some operating
systems support several types of file systems, so you would get
different...
|
| Show full article (1.60Kb) |
| no comments |
|
RELATED THREADS |
|
|
|
|
