gfortran warnings

[TideMan]

In response to another thread Ian Bush suggested that when debugging, we
should always compile using:
gfortran -std=f95 -pedantic -Wall -Wextra -fcheck=all -O

I think it's a good idea, so I tried it (adding -fall-intrinsics so that
I could use command_argument_count and its buddies) and got:
Warning: Nonconforming tab character
on just about every line of my code.

I'm not really worried/interested in this warning. How do I turn it off?
Including -Wtabs does not work for me.

I'm using gfortran Version 4.5.0 in Win XP.

Of course the warnings are annoying, but they don't matter.
But my program crashed on this line:
open(unit=lunnml,file=nmlfile,delim='apostrophe',status='old')
telling me I cannot use delim in f95.
But I've been using that ever since I went to namelists years ago and it
works fine. What is the problem here?

[Steven G. Kargl]

On Wed, 22 Feb 2012 17:07:11 +1300, TideMan wrote:

> In response to another thread Ian Bush suggested that when debugging, we
> should always compile using:
> gfortran -std=f95 -pedantic -Wall -Wextra -fcheck=all -O
>
> I think it's a good idea, so I tried it (adding -fall-intrinsics so that
> I could use command_argument_count and its buddies) and got:
> Warning: Nonconforming tab character
> on just about every line of my code.
>
> I'm not really worried/interested in this warning. How do I turn it off?
> Including -Wtabs does not work for me.
>
> I'm using gfortran Version 4.5.0 in Win XP.
>
> Of course the warnings are annoying, but they don't matter.

Well, it matters if you want to write portable, standard conforming
code. To avoid the warning, I'll suggest that you refer to the
gfortran manual.

> But my program crashed on this line:
> open(unit=lunnml,file=nmlfile,delim='apostrophe',status='old')
> telling me I cannot use delim in f95.

Define crash (as in the actual message that gfortran emitted).

> But I've been using that ever since I went to namelists years ago and it
> works fine. What is the problem here?

See Note 10.33 in the Fortran 95 standard (and yes, I know a Note is
non-normative text).

--
steve

[Tobias Burnus]

TideMan wrote:
> gfortran -std=f95 -pedantic -Wall -Wextra -fcheck=all -O

> But my program crashed on this line:
> open(unit=lunnml,file=nmlfile,delim='apostrophe',status='old')
> telling me I cannot use delim in f95.

Crashing is the wrong word: The compiler just exits with an error:

Error: Fortran 2003: DELIM= at (1) not allowed in Fortran 95

> But I've been using that ever since I went to namelists years ago and it
> works fine. What is the problem here?

It's a bug in gfortran. In Fortran 2003, the DELM= is not only allowed
in OPEN and in INQUIRE but also in the data transfer statements
READ/WRITE. gfortran shares the checking code for both OPEN and
READ/WRITE and wrongly claims that DELIM= is also invalid in OPEN.

Workaround: -std=f2003 (or f2008 or gnu).

I have filled a bug report: http://gcc.gnu.org/bugzilla/post_bug.cgi

Tobias

[Tobias Burnus]

Tobias Burnus wrote:
> I have filled a bug report: http://gcc.gnu.org/bugzilla/post_bug.cgi

I am really looking forward to Bugzilla 4.2 which will show the correct
bug URL after filling a bug. Try:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52335

Tobias

[Ian Bush]

On 22/02/12 04:07, TideMan wrote:
> In response to another thread Ian Bush suggested that when debugging, we
> should always compile using:
> gfortran -std=f95 -pedantic -Wall -Wextra -fcheck=all -O
>
> I think it's a good idea, so I tried it (adding -fall-intrinsics so that
> I could use command_argument_count and its buddies) and got:
> Warning: Nonconforming tab character
> on just about every line of my code.
>
> I'm not really worried/interested in this warning. How do I turn it off?
> Including -Wtabs does not work for me.

Either ignore it or fix it. I've worked with compilers that would reject
code that had tabs in, so I would fix it. It's probably one command in
your editor, or use something like sed or perl,

Ian

[TideMan]

Yes, and I've worked with compilers that required me to punch the code
on Hollerith cards starting at column 7.

But I quite like tabs. They indent my code nicely.
Why can't I have them without the compiler complaining?

[Ian Bush]

Well they're not part of the standard character set, so you can't write
standard conforming code using them. At least that's how I understand it.

The editor I use ( emacs ) allows me to hit tab to indent nicely, but it
actually inserts an appropriate number of spcaes rather than a tab
character. I believe the editor of Satan (aka vi) allows similar, as do
other editors followed by heretics, blasphemers and apostates. Maybe
what you use can do similar?

Ian

[Clive Page]

On 22/02/2012 10:19, Ian Bush wrote:

> The editor I use ( emacs ) allows me to hit tab to indent nicely, but it
> actually inserts an appropriate number of spcaes rather than a tab
> character. I believe the editor of Satan (aka vi) allows similar, as do
> other editors followed by heretics, blasphemers and apostates. Maybe
> what you use can do similar?

I mostly use Notepad++, which is open source, and so not entirely in the
satanic camp, if I understand it rightly. After much experimentation I
discovered a combination of options which produced the same effect, i.e.
can use tab key, and it indents only using spaces. It's a pity that
some editors still don't allow that.


--
Clive Page

[Ian Bush]

On 22/02/12 12:01, Clive Page wrote:
> On 22/02/2012 10:19, Ian Bush wrote:
>
>> The editor I use ( emacs ) allows me to hit tab to indent nicely, but it
>> actually inserts an appropriate number of spcaes rather than a tab
>> character. I believe the editor of Satan (aka vi) allows similar, as do
>> other editors followed by heretics, blasphemers and apostates. Maybe
>> what you use can do similar?
>
> I mostly use Notepad++, which is open source, and so not entirely in the
> satanic camp, if I understand it rightly.

I'm mostly referring to

http://en.wikipedia.org/wiki/Editor_war

actually.

> After much experimentation I
> discovered a combination of options which produced the same effect, i.e.
> can use tab key, and it indents only using spaces. It's a pity that some
> editors still don't allow that.
>
>

Indeed,

Ian

[Gib Bogle]

On 22/02/2012 11:19 p.m., Ian Bush wrote:

> Well they're not part of the standard character set, so you can't write
> standard conforming code using them. At least that's how I understand it.

I wonder why the TAB character is not part of the standard character
set. I've never seen a keyboard without TAB.

[Thomas Koenig]

Clive Page <use...@page2.eu> schrieb:

> I mostly use Notepad++, which is open source, and so not entirely in the
> satanic camp, if I understand it rightly.

Can you get it to work with free source form Fortran? It seems to be stuck in
the middle ages of fixed source.

[Richard Maine]

I have. And I've used Fortran compilers on computers with character sets
that didn't include a tab or anything comparable. At the time of the f77
standard, there were *MAJOR* players in the Fortran market in that kind
of position; I'm not talking obscure systems that nobody had ever heard
of, but rather some of the biggest players in the market at the time. A
Fortran standard that left out, for example, CDC, would have been a
joke. Not a very funny one, though, and not one that would have had any
chance of passing. I wasn't in the standards business yet at the time,
but I'm very sure of that one.

The standard character set started expanding in f90 and later. For
f2003, it includes all the printable ASCII characters. But it is still
only the printable characters. There are no non-printable ones such as
tab.

You'd also run into compatibility problems with multiple existing
incompatible interpretations of tabs. Not to speak of all the pain of
having code that works differently depending on things invisible in a
printout. That's one of the things I really hate about the "make"
utility; tab is not only allowed, but it means something completely
different from blanks. I think you'll find that you couldn't let tab
into the standard character set without at least some cases of that
(although it doesn't have to be as bad as "make", which is really
awfully bad on the subject). For example, I don't see how to avoid the
problem with tabs versus blanks in literal strings.

Just because your keyboard has a tab doesn't mean that the ASCII tab
character has to go into your source code. As Ian mentioned, there are
plenty of editors that will allow you to use the tab key, but will put
an "appropriate" (for some definition - sometimes configurable and
context dependent) number of blanks into the file instead of a literal
tab character. That's what I'm used to having.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain

[Ian Harvey]

You can, if you patch the source. From memory it was a trivial change
as the underlying editor component supports both forms quite well. I
can dig it out if you are interested - it is about time I "upgraded" again.

[Ian Harvey]

But have you ever seen a tab character?

[Gib Bogle]

No. I've never seen a CR or LF character either.

[Erik Toussaint]

So, are they not allowed in a standard conforming program either?

Erik.

[Richard Maine]

I'm not entirely sure how rhetorical that question might be intended,
but I'll answer it anyway, just to be on the safe side.

Just like tab, CR and LF are not in the Fortran character set. They are
therefore not allowed in portable code. I occurs to me that you might be
thinking about line terminators, but those are not part of the Fortran
code. Those might be part of the physical representation of the Fortran
source code, but they do not count as being part of the code.

A processor may choose to allow them as other "graphic" characters, but
a portable program could not use them.

[Erik Toussaint]

On 23-2-2012 22:38, Richard Maine wrote:
> Erik Toussaint<us...@example.net.invalid> wrote:
>> On 23-2-2012 20:36, Gib Bogle wrote:
>>> No. I've never seen a CR or LF character either.
>>
>> So, are they not allowed in a standard conforming program either?
>
> I'm not entirely sure how rhetorical that question might be intended,
> but I'll answer it anyway, just to be on the safe side.

Sorry, I should probably have included a smiley face somewhere in that
post. Nevertheless, I do appreciate the response it evoked. It gives me
some food for thought regarding difference between physical
representation and "metaphysical concept" of source code.

Erik.

[stan]

My keyboard has a windows button, but I'm pretty sure this system (not
windows) would not respond properly and would most likely cause demons
to fly out of the users nose.

Having a button on the keyboard or not really has no bearing or
relevance to the funtionality of a character.

On the other hand, tab and backspace seem to run neck and neck for
causing the most grief from a historical perspective. I'm pretty sure
we'll have to find a way to lasting world peace before we settle the
character set issue. Based on the religious wars waged over the tab
char, one could make the argument that excluding it was the single
wisest choice made during the design. Other languages have disagreed
and paid for their hubris.

My personal theory is that if we could collect all the minutes and
manpower spent on tabs, and focus that collected power we could cure
cancer or maybe even the common cold.

[stan]

Last Halloween; I live near a University with apparently far too many
grad students.

[Luka Djigas]

On Thu, 23 Feb 2012 13:38:05 -0800, nos...@see.signature (Richard Maine)
wrote:

>Erik Toussaint <us...@example.net.invalid> wrote:
>
>> On 23-2-2012 20:36, Gib Bogle wrote:
>
>> > No. I've never seen a CR or LF character either.
>>
>> So, are they not allowed in a standard conforming program either?
>
>I'm not entirely sure how rhetorical that question might be intended,
>but I'll answer it anyway, just to be on the safe side.
>
>Just like tab, CR and LF are not in the Fortran character set. They are
>therefore not allowed in portable code. I occurs to me that you might be
>thinking about line terminators, but those are not part of the Fortran
>code. Those might be part of the physical representation of the Fortran
>source code, but they do not count as being part of the code.
>
>A processor may choose to allow them as other "graphic" characters, but
>a portable program could not use them.

Richard, please, could you elaborate a bit on the difference?

It is an interesting topic, but I'm a bit confused by what do you mean
under "portable code" (in "therefore not allowed in portable code ...")?
Does the compiler take it all as one line, disregarding the line
terminators or ...?

Also, what do you mean under "physical representation"?



-- Luka

[Richard Maine]

Aha. Your describing that as "also" pretty much shows me where to go
with my answer. That's not just an "also"; that is the center of the
whole thing.

The Fortran standard talks about source code "lines". In terms of the
standard, a line is an abstract thing (like most things in the
standard). The standard pointedly says nothing about what a source code
line is made of in concrete terms. This is quite deliberate. Source code
lines could, and have been on, punched cards, paper tape, magnetic
tapes, or anything else. Oh yes, and they could be disk files. Those
things are all possible physical representations of the source code
lines. It is entirely up to the compiler (well, "processor" in
standard-speak) to define the relationship between the physical
representation and the abstract Fortran concept - what holes would be
punched in the card, or what bits would be on the disk in order to
represent a line as described in the standard.

The CR and/or LF characters that you'll find in common text file formats
today are just part of that physical representation. They are how the
compiler keeps track of what is in each line. They are not part of the
line as described by the standard. They are instead part of the physical
representation. That's the stuff that the standard says nothing about.

If, to take the usual Unix convention for example, the compiler uses an
LF as part of its physical representation of a line, then you aren't
going to be able to have an LF that's part of the abstract line
described by the Fortran standard. That's because if you try, it will
look like the end of the line instead of like something in the content
of the line. (Yes, there could be ways to "escape" that, but the usual
Unix convenstion doesn't). On the other hand, there are file formats
where there is no particular problem in having an LF character. The
record size headers typical of sequential unformatted files alow the
record to contain completely arbitrary content, including LF characters.
There exist systems that use formats like that for text files as well as
for unformatted ones.

As for what I mean by "portable code".... well, I'd hope that was
largely self-evident. Portable code is code that you can easily move
(aka port) from one system to another. There are various degrees of
portable. Depending on context, code might be referred to as portable if
it could be moved from one system to another with relatively small and
simple changes, or it might be called portable only if it could be moved
with no changes at all.

You might be thinking that standard conformance is enough to ensure
portability. If so, you would be wrong. The standard itself is quite
explicit about that. From 1.5, Conformance, in f2003

"Because a standard-conforming program may place demands on a
processor that are not within the scope of the standard or may include
standard items that are not portable,... conformance to this standard
does not ensure that a program will execute consistently on all or any
standard-conforming processors."

If you did have a processor (compiler) that allowed such things as tabs,
CR, and LF in source code lines, that would count as being standard
conforming, but not portable. Please note that I said "in source code
lines." The CR and/or LF that often are used as part of the physical
representation of a source code line do not count as being part of the
source code line. Actually, a tab could also concievably be considered
as part of the physical representation of some number of blanks in the
source code line, but in that case you'd have a physical representation
that was not necessarily portable. I don't think you'll find that most
compilers treat tabs consistently enough to really count quite like
that, but it is at least possible (easy, even).

I could go on a bit more than this already long reply. There are plenty
of related subtleties. But I think that will have to do for now.

[mecej4]

Perhaps, an examination of the role of CR and LF from a historical point
would help. Before the advent of teletype and CRT terminals,
card-readers were used for source code input. What we call a line of
source code now was a card and, therefore, no CR or LF was needed. A
thin film of air was enough to separate cards.

In such a scenario, CR and LF entered the picture only when source code
and program output were output to a line-printer. If the output was to a
card-punch, CR and LF were not in the picture.

I remember struggling with the concept of a "permanent file system" with
a tree-structure and making unsuccessful attempts to visualize the file
system in terms of card-decks, when such a "new-fangled" system replaced
an older, card-oriented computer system at a university computer center.

-- mecej4

[glen herrmannsfeldt]

mecej4 <mec...@nospam.operamail.com> wrote:
(snip)

>>> Also, what do you mean under "physical representation"?

(snip)

>> The CR and/or LF characters that you'll find in common text file formats
>> today are just part of that physical representation. They are how the
>> compiler keeps track of what is in each line. They are not part of the
>> line as described by the standard. They are instead part of the physical
>> representation. That's the stuff that the standard says nothing about.

(snip)

> Perhaps, an examination of the role of CR and LF from a historical
> point would help. Before the advent of teletype and CRT terminals,
> card-readers were used for source code input. What we call a line of
> source code now was a card and, therefore, no CR or LF was needed. A
> thin film of air was enough to separate cards.

> In such a scenario, CR and LF entered the picture only when source code
> and program output were output to a line-printer. If the output was to a
> card-punch, CR and LF were not in the picture.

Card readers, punches, and line printers used by IBM, at least through
S/360, didn't use CR or LF. A line (record) was transfered with
one channel command. I have printed lines with CR and LF on
the 1403, and each prints just like a single blank.

> I remember struggling with the concept of a "permanent file system" with
> a tree-structure and making unsuccessful attempts to visualize the file
> system in terms of card-decks, when such a "new-fangled" system replaced
> an older, card-oriented computer system at a university computer center.

Many DEC systems were designed around teletype terminals and paper
tape readers, using usually CRLF line terminators. That was inherited
by CP/M and then MS-DOS.

IBM terminals like the 2741 don't use ASCII or EBCDIC, and do have
some kind of CR character.

-- glen

[David Thompson]

On Sat, 25 Feb 2012 08:20:01 +0000 (UTC), glen herrmannsfeldt
<g...@ugcs.caltech.edu> wrote:

> mecej4 <mec...@nospam.operamail.com> wrote:
> (snip)
>
> >>> Also, what do you mean under "physical representation"?
>
> (snip)
> >> The CR and/or LF characters that you'll find in common text file formats
> >> today are just part of that physical representation. They are how the
> >> compiler keeps track of what is in each line. They are not part of the
> >> line as described by the standard. They are instead part of the physical
> >> representation. That's the stuff that the standard says nothing about.
>
> (snip)
> > Perhaps, an examination of the role of CR and LF from a historical
> > point would help. Before the advent of teletype and CRT terminals,
> > card-readers were used for source code input. What we call a line of
> > source code now was a card and, therefore, no CR or LF was needed. A
> > thin film of air was enough to separate cards.
>
> > In such a scenario, CR and LF entered the picture only when source code
> > and program output were output to a line-printer. If the output was to a
> > card-punch, CR and LF were not in the picture.
>
> Card readers, punches, and line printers used by IBM, at least through
> S/360, didn't use CR or LF. A line (record) was transfered with
> one channel command. I have printed lines with CR and LF on
> the 1403, and each prints just like a single blank.
>

Yes, also HT and BS and probably more I didn't run into.

2780/3780 bisync protocol could transmit F-E codes like CR within a
'card' or 'line' but not comm codes like STX unless you had the
'transparency' feature. But I don't know what real hardware did with
them once received; I worked almost entirely with emulators where it
was software that had to cope -- and sometimes didn't.

327x bisync could transmit at least CR LF and IIRC HT to a (nominally)
remote printer, and my doc said they could 'display' on the screen as
blanks before printing but I never had occasion to try that. This may
well have been dependent on the particular device(s), as over several
decades 3270s went through pretty major changes while maintaining an
amazing, even frightening, level of compatibility.

SNA versions of both 3780 and 327x could of course transmit any
character, but it was still up to the device(s) what to do with them.

> > I remember struggling with the concept of a "permanent file system" with
> > a tree-structure and making unsuccessful attempts to visualize the file
> > system in terms of card-decks, when such a "new-fangled" system replaced
> > an older, card-oriented computer system at a university computer center.
>

Imagine a connected maze of bookshelves with decks placed on them
seemingly at random -- or perhaps decks in paper shrouds that prevent
you from seeing the handy markings on the 12-edge. <G>

> Many DEC systems were designed around teletype terminals and paper
> tape readers, using usually CRLF line terminators. That was inherited
> by CP/M and then MS-DOS.
>

Treating teletype as a generic (which really we shouldn't) yes, plus
to a significant extent 'glass TTY' video terminals using the same
ASCII charset and line protocols. Other minis I saw like DG, HP, Prime
used the same terminals but I don't know about file formats.

> IBM terminals like the 2741 don't use ASCII or EBCDIC, and do have
> some kind of CR character.
>

2741 used PTTC which had a combined CRLF aka NewLine code. The
Selectric mechanism couldn't do CR; to move left on the same line you
used multiple backspaces. I worked at a place with magtape Selectrics
(MT/ST) which were also automatic, but not remote; same issue.