what does the standard have to say to the following? This line:
character(len=*), parameter :: newline = new_line("a")
makes ifort (Version 11.1 on Linux) say:
code.f90(4): error #6263: This intrinsic function is invalid in constant expressions. [NEW_LINE]
character(len=*), parameter :: newline = new_line("a")
-----------------------------------------^
compilation aborted for code.f90 (code 1)
> what does the standard have to say to the following? This line:
> character(len=*), parameter :: newline = new_line("a")
> makes ifort (Version 11.1 on Linux) say:
> code.f90(4): error #6263: This intrinsic function is invalid in constant
> expressions. [NEW_LINE]
> character(len=*), parameter :: newline = new_line("a")
> -----------------------------------------^
> compilation aborted for code.f90 (code 1)
> The code compiles just fine in gfortran.
> Paul
I think it should work in F2003 (I didn't try to track down F2008). The rules for initialization expressions (7.1.6) allow a specification inquiry with a constant argument and page 125 says NEW_LINE is a specification inquiry function.
> On 8/16/12 2:53 PM, Paul Anton Letnes wrote:
>> Hi,
>> what does the standard have to say to the following? This line:
>> character(len=*), parameter :: newline = new_line("a")
>> makes ifort (Version 11.1 on Linux) say:
>> code.f90(4): error #6263: This intrinsic function is invalid in constant
>> expressions. [NEW_LINE]
>> character(len=*), parameter :: newline = new_line("a")
>> -----------------------------------------^
>> compilation aborted for code.f90 (code 1)
>> The code compiles just fine in gfortran.
>> Paul
> I think it should work in F2003 (I didn't try to track down F2008). The
> rules for initialization expressions (7.1.6) allow a specification
> inquiry with a constant argument and page 125 says NEW_LINE is a
> specification inquiry function.
> Dick Hendrickson
If F2003 says it's OK, I'd expect F2008 to say the same? Anyway, this will make life somewhat complicated if it can't be resolved... Is there a standard way of determining a character, parameter :: ... which contains the "newline" character(s)?
> If F2003 says it's OK, I'd expect F2008 to say the same? Anyway, this
> will make life somewhat complicated if it can't be resolved... Is there
> a standard way of determining a character, parameter :: ... which
> contains the "newline" character(s)?
A 100% equivalent doesn't exist, but achar(10) should work.
Unless you have an UCS-4 character; then you should use char(10,kind=...).
(I admit I find new_line one of the less useful new intrinsics - and I had wished a method to obtain Windows' crlf via an intrinsic.)
From the standard:
Result Value.
Case (i): If A is default character and the character in position 10 of the ASCII collating sequence is representable in the default character set, then the result is ACHAR (10).
Case (ii): If A is ASCII character or ISO 10646 character, then the result is CHAR (10, KIND (A)).
Case (iii): Otherwise, the result is a processor-dependent character that represents a newline in output to files connected for formatted stream output if there is such a character.
Case (iv): Otherwise, the result is the blank character.
> On 08/17/2012 09:22 AM, Paul Anton Letnes wrote:
>> If F2003 says it's OK, I'd expect F2008 to say the same? Anyway, this
>> will make life somewhat complicated if it can't be resolved... Is there
>> a standard way of determining a character, parameter :: ... which
>> contains the "newline" character(s)?
> A 100% equivalent doesn't exist, but achar(10) should work.
> Unless you have an UCS-4 character; then you should use char(10,kind=...).
> (I admit I find new_line one of the less useful new intrinsics - and I
> had wished a method to obtain Windows' crlf via an intrinsic.)
> From the standard:
> Result Value.
> Case (i): If A is default character and the character in position 10 of
> the ASCII collating sequence is representable in the default character
> set, then the result is ACHAR (10).
> Case (ii): If A is ASCII character or ISO 10646 character, then the
> result is CHAR (10, KIND (A)).
> Case (iii): Otherwise, the result is a processor-dependent character
> that represents a newline in output to files connected for formatted
> stream output if there is such a character.
> Case (iv): Otherwise, the result is the blank character.
> Tobias
Ah, I see. I thought that achar(10) was a nonstandard way of doing this, but it looks like it should be fine?
Paul Anton Letnes <paul.anton.let...@nospam.gmail.kthxbai.com> wrote:
> On 17.08.12 09:43, Tobias Burnus wrote:
> > On 08/17/2012 09:22 AM, Paul Anton Letnes wrote:
> >> If F2003 says it's OK, I'd expect F2008 to say the same? Anyway, this
> >> will make life somewhat complicated if it can't be resolved... Is there
> >> a standard way of determining a character, parameter :: ... which
> >> contains the "newline" character(s)?
> > A 100% equivalent doesn't exist, but achar(10) should work.
> Ah, I see. I thought that achar(10) was a nonstandard way of doing this,
> but it looks like it should be fine?
Achar(10) is perfectly standard. I agree with Tobias about new_line
being of limitted utility. As you can see from the quote above, new_line
is specifically defined to be achar(10) in most cases. I'd say that the
only cases where it has much application are those where you are looking
for the new_line character used by a non-default character kind. That
would be pretty rare. In particular, that comes up a *LOT* less often
than people getting confused by what new_line means and thinking it will
return the character (or character sequence) used by the OS to represent
a newline in a file. As in, I've never actually seen a useful
application for new_line in practice (largely because I've never worked
with a compiler that supports a character set where it does anything
useful), but the confusion happens regularly.
I suspect you might be thinking of the "F" language, which was an
f90/f95 subset. If I recall correctly, F omitted the achar intrinsic as
part of its subsetting. Or maybe I have it backwards and they omitted
char, but I think it was achar.
-- Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
> what does the standard have to say to the following? This line:
> character(len=*), parameter :: newline = new_line("a")
> makes ifort (Version 11.1 on Linux) say:
> code.f90(4): error #6263: This intrinsic function is invalid in constant
> expressions. [NEW_LINE]
> character(len=*), parameter :: newline = new_line("a")
> -----------------------------------------^
> compilation aborted for code.f90 (code 1)
It seems we overlooked that when adding the function many years ago - I have filed bug report DPD200235439 about it. F2003 explicitly calls out NEW_LINE as a "specification inquiry function" and F2008 generalizes the rule to include all inquiry functions.
-- Steve Lionel
Developer Products Division
Intel Corporation
Merrimack, NH
On Friday, August 17, 2012 9:05:50 AM UTC-4, Richard Maine wrote:
> Paul Anton Letnes <paul.anton.let...@nospam.gmail.kthxbai.com> wrote:
> > On 17.08.12 09:43, Tobias Burnus wrote:
> > > On 08/17/2012 09:22 AM, Paul Anton Letnes wrote:
> > >> If F2003 says it's OK, I'd expect F2008 to say the same? Anyway, this
> > >> will make life somewhat complicated if it can't be resolved... Is there
> > >> a standard way of determining a character, parameter :: ... which
> > >> contains the "newline" character(s)?
> > > A 100% equivalent doesn't exist, but achar(10) should work.
> > Ah, I see. I thought that achar(10) was a nonstandard way of doing this,
> > but it looks like it should be fine?
> Achar(10) is perfectly standard. I agree with Tobias about new_line
Now I am confused. Achar(10) is newline in POSIX, but after years of reading in this newsgroup how something couldn't be made part of the fortran standard because a CPU with 60 bit words from the 1950s couldn't deal with it, how can achar(10) be called the standard for newline? What about Windows? I think I am misunderstanding something. What is it intended to return if not the character sequence used by the OS? The standard quoted above says "processor" but doesn't a fortran processor include the OS?
On 2012-08-17 23:59:04 +0000, Daniel Feenberg said:
> Now I am confused. Achar(10) is newline in POSIX, but after years of > reading in this newsgroup how something couldn't be made part of the > fortran standard because a CPU with 60 bit words from the 1950s > couldn't deal with it, how can achar(10) be called the standard for > newline? What about Windows? I think I am misunderstanding something. > What is it intended to return if not the character sequence used by the > OS? The standard quoted above says "processor" but doesn't a fortran > processor include the OS?
The new line character, or achar( 10), or whatever, is only a signal
to the rtl to end the record.
Strange short character sets didn't have end-of-record characters,
the file had a record structure.
IMNSHO, the worst thing new_line() does is make any future attempt
at classifying characters a little bit harder, because it might return
a control character or it might return a graphic character, and that
will likely require a special case for clarity. Yuk.
Daniel Feenberg <feenb...@gmail.com> wrote:
> Now I am confused. Achar(10) is newline in POSIX, but after years of
> reading in this newsgroup how something couldn't be made part of the
> fortran standard because a CPU with 60 bit words from the 1950s couldn't
> deal with it, how can achar(10) be called the standard for newline? What
> about Windows? I think I am misunderstanding something. What is it
> intended to return if not the character sequence used by the OS? The
> standard quoted above says "processor" but doesn't a fortran processor
> include the OS?
See the part of my post where I commented about how often people were
confused about what the new_line intrinsic does. Yes, your confusion is
shared by many people. The intrinsic does *NOT* do what you think it
does. In particular, it has nothing to do with what character or
characters are used to represent the end of a line in a text file. It
doesn't even imply that the end of a line in a text file is represented
by a sequence of characters. Text file lines could be represented by
header with the line length, much like typical unformated file records.
I have worked on multiple systems with representations like that.
The achar(10) (or other character returned by new_line) is used as a
flag to be interpreted by the Fortran runtime library. That runtime
library is then responsible for doing whatever is needed to terminate
the line (record). This does not have to be just copying the achar(10)
to the file. On a Windows system, the Fortran runtimes should put a
cr/lf sequence in the file when an achar(10) is encountered.
This is, by the way, pretty much identical to what the C standard
specifies. That is no coincidence. The achar(10) handling stuff was
added to Fortran as part of C interop. If I recall correctly, it applies
only to formatted stream files.
-- Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
