gfortran diagnostics and so on
James Van Buskirk
cost the programmer time, I thought I would point out a few that I
have been bitten by lately with gfortran.
C:\gfortran\clf\bugs>C:\gfortran\win64\bin\x86_64-pc-mingw32-gfortran -v
Using built-in specs.
Target: x86_64-pc-mingw32
Configured with:
../trunk/configure --prefix=/home/FX/win64 --with-sysroot=/home
/FX/win64 --build=i386-pc-mingw32 --target=x86_64-pc-mingw32 --enable-languages=
c,fortran --with-gmp=/home/FX/local --disable-werror --disable-nls --enable-thre
ads=win32
Thread model: win32
gcc version 4.3.0 20070920 (experimental) [trunk revision 128387] (GCC)
C:\gfortran\clf\bugs>type bug1_backslash.f90
! File: bug1_backslash.f90
! Public domain 2007 James Van Buskirk
program bug1_backslash
implicit none
write(*,'(a)') 'C:\windows\bug1'
end program bug1_backslash
! End of file: bug1_backslash.f90
C:\gfortran\clf\bugs>C:\gfortran\win64\bin\x86_64-pc-mingw32-gfortran
bug1_backs
lash.f90 -obug1_backslash
C:\gfortran\clf\bugs>bug1_backslash
C:\windowug1
C:\gfortran\clf\bugs>C:\gfortran\win64\bin\x86_64-pc-mingw32-gfortran
bug1_backs
lash.f90 -fno-backslash -obug1_backslash
C:\gfortran\clf\bugs>bug1_backslash
C:\windows\bug1
C:\gfortran\clf\bugs>type bug2_transfer.f90
! File: bug2_transfer.f90
! Public domain 2007 James Van Buskirk
program bug2_transfer
use ISO_C_BINDING
implicit none
type(C_PTR) C_NULL_PTR1
C_NULL_PTR1 = transfer(0_C_INTPTR_T,C_NULL_PTR1)
write(*,'(a)') trim(merge('.TRUE. ','.FALSE.', &
C_ASSOCIATED(C_NULL_PTR1)))
end program bug2_transfer
! End of file: bug2_transfer.f90
C:\gfortran\clf\bugs>C:\gfortran\win64\bin\x86_64-pc-mingw32-gfortran
bug2_trans
fer.f90 -obug2_transfer
bug2_transfer.f90:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
C:\gfortran\clf\bugs>type bug3_structure_constructor.f90
! File: bug3_structure_constructor.f90
! Public domain 2007 James Van Buskirk
module bug3_mod
use ISO_C_BINDING
implicit none
private
public bug3
type bug3
integer(C_INT) n
type(C_PTR) p
character(kind=C_CHAR) c
end type bug3
end module bug3_mod
program bug3_structure_constructor
use ISO_C_BINDING
use bug3_mod
implicit none
type(bug3) result
result = bug3( &
17, & ! n
C_NULL_PTR, & ! p -- errors here
C_NULL_PTR ) ! c -- should error here
end program bug3_structure_constructor
! End of file: bug3_structure_constructor.f90
C:\gfortran\clf\bugs>C:\gfortran\win64\bin\x86_64-pc-mingw32-gfortran
bug3_struc
ture_constructor.f90 -obug3_structure_constructor
bug3_structure_constructor.f90:24.17:
C_NULL_PTR, & ! p -- errors here
1
Error: Can't convert TYPE(c_ptr) to CHARACTER(1) at (1)
C:\gfortran\clf\bugs>type bug4_structure.f90
! File: bug4_structure.f90
! Public domain 2007 James Van Buskirk
module bug4_mod
implicit none
type bug4
! Intentionally left blank; should error up here
end type bug4
end module bug4_mod
program bug4_structure
use bug4_mod
implicit none
type(bug4) t
t = bug4()
write(*,*) t
end program bug4_structure
! End of file: bug4_structure.f90
C:\gfortran\clf\bugs>C:\gfortran\win64\bin\x86_64-pc-mingw32-gfortran
bug4_struc
ture.f90 -obug4_structure
bug4_structure.f90:13.13:
type(bug4) t
1
Error: Derived type 'bug4' at (1) is being used before it is defined
bug4_structure.f90:15.11:
t = bug4()
1
Error: Derived type 'bug4' at (1) is being used before it is defined
bug4_structure.f90:16.15:
write(*,*) t
1
Error: Symbol 't' at (1) has no IMPLICIT type
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
Tobias Burnus
> C:\gfortran\clf\bugs>type bug4_structure.f90
> ! File: bug4_structure.f90
> ! Public domain 2007 James Van Buskirk
> module bug4_mod
> implicit none
> type bug4
> ! Intentionally left blank; should error up here
> end type bug4
> end module bug4_mod
If you want to have an error message at that place, use -std=f95.
Fortran 2003 allows types without components.
> C:\gfortran\clf\bugs>C:\gfortran\win64\bin\x86_64-pc-mingw32-gfortran
> bug4_struc
> ture.f90 -obug4_structure
> bug4_structure.f90:13.13:
> type(bug4) t
> 1
> Error: Derived type 'bug4' at (1) is being used before it is defined
This indicates that your gfortran is too old. In terms of component-
free TYPEs, it was a three-step process:
1. Allow it in TYPE
2. Realize that "type(bug4) t" does not work, fix it
3. Realize that "t = bug4()" does not work, fix it
Tobias
Tobias Burnus
>
>
> [...] -fno-backslash [...]
> C:\windows\bug1
I don't know how to handle this best. Backslashes are difficult as
some people expect that "\" prints a backslash, others want to have
"\n" as new line -- and both want to have their choice as default.
With either choice, you have unhappy users. But I am open to
suggestions.
In the case above, the "\b" is transformed into <bell> but as \w does
not exist, it is not transformed as kept as "\" The current
implementation allows for:
character :: backslash = '\'
print *, 'Hello\nyou'
which is neat. But it causes your problem above. Now very Windows-
friendly, but using achar(92) is the only reliable way to get
backslashes which work out of the box with all compilers.
> C:\gfortran\clf\bugs>type bug2_transfer.f90
> C_NULL_PTR1 = transfer(0_C_INTPTR_T,C_NULL_PTR1)
> bug2_transfer.f90:0: internal compiler error: Segmentation fault
Filled as bugreport:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34199
> 17, & ! n
> C_NULL_PTR, & ! p -- errors here
> C_NULL_PTR ) ! c -- should error here
>
>
> C_NULL_PTR, & ! p -- errors here
> 1
> Error: Can't convert TYPE(c_ptr) to CHARACTER(1) at (1)
I agree that this can be done better (at least it should be after the
comma, better below the C of C_NULL_PTR.
Tobias
Richard Maine
> I don't know how to handle this best. Backslashes are difficult as
> some people expect that "\" prints a backslash, others want to have
> "\n" as new line -- and both want to have their choice as default.
> With either choice, you have unhappy users. But I am open to
> suggestions.
Well, in f0003, backslash is part of the standard Fortran character set.
So I'll find it awfully hard to accept as reasonable a default that
doesn't conform to the standard. But then I'm one of those who has
always thought that doing backslash processing on Fortan code was an
unreasonable default, so just consider me biased.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
James Van Buskirk
news:1b367c29-7d4b-4a5e...@l1g2000hsa.googlegroups.com...
> On Nov 22, 9:17 pm, "James Van Buskirk" <not_va...@comcast.net> wrote:
>> C:\gfortran\clf\bugs>type bug4_structure.f90
>> ! File: bug4_structure.f90
>> ! Public domain 2007 James Van Buskirk
>> module bug4_mod
>> implicit none
>> type bug4
>> ! Intentionally left blank; should error up here
>> end type bug4
>> end module bug4_mod
> If you want to have an error message at that place, use -std=f95.
> Fortran 2003 allows types without components.
Cool. I didn't realize so much had changed since f95.
>> bug4_structure.f90:13.13:
>> type(bug4) t
>> 1
>> Error: Derived type 'bug4' at (1) is being used before it is defined
> This indicates that your gfortran is too old. In terms of component-
> free TYPEs, it was a three-step process:
> 1. Allow it in TYPE
> 2. Realize that "type(bug4) t" does not work, fix it
> 3. Realize that "t = bug4()" does not work, fix it
Old is relative. At FX's web page I found
http://quatramaran.ens.fr/~coudert/gfortran/gfortran-windows.exe 10/18/07
and
http://quatramaran.ens.fr/~coudert/gfortran/win64.zip 9/21/07
so I'm up to date as far as Windows is concerned. I would like to have
a more current version as there are some bullets I wish to bounce off of
it. Example:
program bug4a
implicit none
type bug4
! Intentionally left empty
end type bug4
type compound
integer a
type(bug4) b
type(bug4) c
integer d
type(bug4) e
end type compound
type(bug4) t
type(compound) c
type(bug4), parameter :: f = bug4()
type(compound), parameter :: g = compound(1,f,bug4(),4,f)
type other
real x(0)
end type other
c = compound(1,t,t,4,t)
write(*,*) c
write(*,*) g%d
write(*,*) size(transfer(1,[bug4()]))
write(*,*) size(transfer(1,['']))
write(*,*) size(transfer(1,[other()]))
write(*,*) transfer(transfer([1],[bug4()]),[1],size[1])
end program bug4a
James Van Buskirk
> On Nov 22, 9:17 pm, "James Van Buskirk" <not_va...@comcast.net> wrote:
>> write(*,'(a)') 'C:\windows\bug1'
>> C:\windowug1
>> [...] -fno-backslash [...]
>> C:\windows\bug1
> I don't know how to handle this best. Backslashes are difficult as
> some people expect that "\" prints a backslash, others want to have
> "\n" as new line -- and both want to have their choice as default.
> With either choice, you have unhappy users. But I am open to
> suggestions.
Andy was kind enough to change the default to -fno-backslash for
Windows g95, following the logic that it's quite common to want to
specify paths with embedded backslashes on that platform. The
C escape sequences are mostly just an annoyance to be worked around
for Fortran programmers. As a C programmer writing a Fortran
compiler it may not always be apparent how confusing and error-prone
the C way of doing things is (to a Fortran programmer) but it is as
bad as that and worse. Same goes for internal representations of
LOGICAL variables.
> In the case above, the "\b" is transformed into <bell>
Here is the confusing and error-prone stuff alluded to above. '\a' is
<BEL> (alert) but '\b' is <BS>, erasing the 's' from 'windows' preceding
it. Of course the actual path wasn't printed out but passed to a
Win32 API function. Since it was obviously correct and I was in
unfamiliar territory, I spent time looking at other stuff before
printing out what gfortran thought the path was.
> but as \w does
> not exist, it is not transformed as kept as "\" The current
> implementation allows for:
> character :: backslash = '\'
Perhaps you intended
character :: backslash = '\\'
? But why not
character :: backslash = achar(92)
?
> print *, 'Hello\nyou'
> which is neat. But it causes your problem above. Now very Windows-
> friendly, but using achar(92) is the only reliable way to get
> backslashes which work out of the box with all compilers.
What's wrong with the standard-conforming
print *, 'Hello'//achar(10)//'you'
?
>> C:\gfortran\clf\bugs>type bug2_transfer.f90
>> C_NULL_PTR1 = transfer(0_C_INTPTR_T,C_NULL_PTR1)
>> bug2_transfer.f90:0: internal compiler error: Segmentation fault
> Filled as bugreport:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34199
Thanks.
>> 17, & ! n
>> C_NULL_PTR, & ! p -- errors here
>> C_NULL_PTR ) ! c -- should error here
>> C_NULL_PTR, & ! p -- errors here
>> 1
>> Error: Can't convert TYPE(c_ptr) to CHARACTER(1) at (1)
> I agree that this can be done better (at least it should be after the
> comma, better below the C of C_NULL_PTR.
This was the worst of the bugs in terms of time spend until I
figured out what was happening. It's kind of like in C++ where
a common bug is omitting the semicolon at the end of a class
definition. The bug is seen soon after the include line for
the class header file, where the missing semicolon is nowhere to
be seen (although this last sentence reads comically).
Even if the position of the bug is imperfectly located, the name
of the component might be given in the error statement without
too much difficulty. This may make it easier for the Fortran
programmer to figure out his mistake. I was really blind to this
one. Or maybe I was just tired.
Richard Maine
> "Tobias Burnus" <bur...@net-b.de> wrote in message
> news:1b367c29-7d4b-4a5e...@l1g2000hsa.googlegroups.com...
> > Fortran 2003 allows types without components.
>
> Cool. I didn't realize so much had changed since f95.
That's been something that would have been a useful feature (and thus an
annoying omission) all along. There have been contexts where such a type
would be useful and one had to "fake it" by adding a bogus component. It
didn't come up a lot, but there were some times.
With the OOF stuff of f2003, it comes up a lot. A type with no
components turns out to be a very natural thing to have in conjuction
with some of the OOF features. People wowuld have run into it (and
bitched) a lot if the feature hadn't been added. Or perhaps more
accurately, if the pointless restriction hadn't been lifed.
Richard Maine
> using achar(92) is the only reliable way to get
> backslashes which work out of the box with all compilers.
Well, all standard-conforming compilers. I seem to recall that F doesn't
like achar. I might have gotten that confused, as I don't use F, but I
remember something like that at one time.
Tobias Burnus
> Tobias Burnus <bur...@net-b.de> wrote:
> > I don't know how to handle this best. Backslashes are difficult as
> > some people expect that "\" prints a backslash, others want to have
> > "\n" as new line -- and both want to have their choice as default.
> > With either choice, you have unhappy users. But I am open to
> > suggestions.
>
> Well, in f0003, backslash is part of the standard Fortran character set.
> So I'll find it awfully hard to accept as reasonable a default that
> doesn't conform to the standard. But then I'm one of those who has
> unreasonable default, so just consider me biased.
I am not saying that I'm happy with the current choice, but changing a
default setting has to be weighted: Is the change better for most
users or are more users affected by the change? I will rise the point
on the gfortran list and filled http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34203
to make sure I don't forget about it.
James Van Buskirk wrote:
> Andy was kind enough to change the default to -fno-backslash for
> Windows g95, following the logic that it's quite common to want to
> specify paths with embedded backslashes on that platform.
I wonder whether it makes more sense to do a platform-specific change
(mainly affected, prevents changing makefiles on other platforms) or
change the default on all platforms (consistency). I also would like
to see a warning for \w as it is not a C escape sequence.
> > This indicates that your gfortran is too old.
> Old is relative. At FX's web page I found [...]
I now wrote FX an email to ask him for an update of the Windows
compiler.
> I would like to have a more current version as there are some
> bullets I wish to bounce off of it. Example:
>
> program bug4a
[...]
> write(*,*) size(transfer(1,[other()]))
The "other" constructor needs a real argument.
> write(*,*) transfer(transfer([1],[bug4()]),[1],size[1])
The "size[1]" is wrong syntax. I don't know whether this was intended.
gfortran diagnoses both errors, however, after the last one it does
not fully recover and crashes. This is now tracked as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34202
Thanks to both of your for your comments.
Richard Maine wrote:
> Tobias Burnus <bur...@net-b.de> wrote:
> > using achar(92) is the only reliable way to get
> > backslashes which work out of the box with all compilers.
>
> Well, all standard-conforming compilers. I seem to recall that F doesn't
> like achar. I might have gotten that confused, as I don't use F, but I
> remember something like that at one time.
Well, with working I meant and mean standard-conforming Fortran 9x/
2003 compilers. But thanks for pointing out that F might not allow it.
(I tend to forget about F as I don't use it and it does not allow
namelist i/o or Fortran 2003 features.)
Tobias
glen herrmannsfeldt
> On Nov 22, 11:58 pm, nos...@see.signature (Richard Maine) wrote:
(snip)
>>Well, in f0003, backslash is part of the standard Fortran character set.
>>So I'll find it awfully hard to accept as reasonable a default that
>>doesn't conform to the standard. But then I'm one of those who has
>>always thought that doing backslash processing on Fortran code was an
>>unreasonable default, so just consider me biased.
I agree. I don't mind it as an option, but it shouldn't
be the default. (Unless it gets added to the standard.)
(It seems that it is part of Fortran 2003 (15.1.1) if
C_CHAR.NE.-1 in ISO_C_BINDING. This should apply to character
constants of kind C_CHAR, at least.)
> I am not saying that I'm happy with the current choice, but changing a
> default setting has to be weighted: Is the change better for most
> users or are more users affected by the change? I will rise the point
> on the gfortran list and filled http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34203
> to make sure I don't forget about it.
My guess is that most users don't put backslash in strings with
or without escapes, but that is a guess.
> James Van Buskirk wrote:
>>Andy was kind enough to change the default to -fno-backslash for
>>Windows g95, following the logic that it's quite common to want to
>>specify paths with embedded backslashes on that platform.
> I wonder whether it makes more sense to do a platform-specific change
> (mainly affected, prevents changing makefiles on other platforms) or
> change the default on all platforms (consistency). I also would like
> to see a warning for \w as it is not a C escape sequence.
It is C tradition not to warn for such escapes.
But then Fortran isn't C, and I wouldn't be against a warning.
There are a number of uses for backslash in strings other
than windows file names. TeX code, regular expression escapes,
unix shell escapes, to name a few. I could imagine Fortran
programs generating TeX output or unix shell commands.
I do remember using grep to search for \\ in a TeX file:
grep \\\\\\\\ *.tex
-- glen
Craig Dedo
news:1i7zirl.hdl6kepl696lN%nos...@see.signature...
I wholeheartedly agree with Richard. Because the backslash is part of the
standard Fortran character set, the default behavior should be the printable
character, **NOT** some kind of magic introductory character that transforms the
interpretation of following character(s). Compiler defaults should always
follow the Fortran standard, wherever applicable.
Just because C uses backslash as a magic introductory character does not
mean that Fortran should follow that practice. Although some may disagree, I
have always thought that part of the spirit of Fortran is that it is designed to
make life easy for the application developer. What you write on the blackboard
is what you write in the source code. Among other things, that means that
printable characters are exactly that, no more and no less.
There are reasonable alternatives for programmers who want the C language
behavior. The one I like best is to use one of the popular extensions to
designate a particular literal string according to the C language.
If a programmer wants control characters in character strings, the
programmer can always use the CHAR() or ACHAR() intrinsic functions. The
programmer also can define a module that defines all of the control characters
as named constants. I have done that and it works very well.
--
Craig Dedo
17130 W. Burleigh Place
P. O. Box 423
Brookfield, WI 53008-0423
Voice: (262) 783-5869
Fax: (262) 783-5928
Mobile: (414) 412-5869
E-mail: <cd...@wi.rr.com> or <cr...@ctdedo.com>
Dr Ivan D. Reid
wrote in <r_qdnU_qSbm2ONva...@comcast.com>:
> There are a number of uses for backslash in strings other
> than windows file names. TeX code, regular expression escapes,
> unix shell escapes, to name a few. I could imagine Fortran
> programs generating TeX output or unix shell commands.
...and PostScript(TM) graphics.
--
Ivan Reid, School of Engineering & Design, _____________ CMS Collaboration,
Brunel University. Ivan.Reid@[brunel.ac.uk|cern.ch] Room 40-1-B12, CERN
Dan Nagle
Dr Ivan D. Reid wrote:
> On Fri, 23 Nov 2007 02:07:14 -0800, glen herrmannsfeldt <g...@ugcs.caltech.edu>
> wrote in <r_qdnU_qSbm2ONva...@comcast.com>:
>
>> There are a number of uses for backslash in strings other
>> than windows file names. TeX code, regular expression escapes,
>> unix shell escapes, to name a few. I could imagine Fortran
>> programs generating TeX output or unix shell commands.
>
> ...and PostScript(TM) graphics.
But surely all of these are rather specialized uses.
The default should be that a Fortran compiler compiles Fortran.
A specialized use can be isolated in a file or a few files
and compiled separately with special flags to do special things.
--
Dan Nagle
Purple Sage Computing Solutions, Inc.
Steven G. Kargl
glen herrmannsfeldt <g...@ugcs.caltech.edu> writes:
> Tobias Burnus wrote:
>
>> On Nov 22, 11:58 pm, nos...@see.signature (Richard Maine) wrote:
>
> (snip)
>
>>>Well, in f0003, backslash is part of the standard Fortran character set.
>>>So I'll find it awfully hard to accept as reasonable a default that
>>>doesn't conform to the standard. But then I'm one of those who has
>>>always thought that doing backslash processing on Fortran code was an
>>>unreasonable default, so just consider me biased.
>
> I agree. I don't mind it as an option, but it shouldn't
> be the default. (Unless it gets added to the standard.)
>
gfortran is primarily a Fortran 95 compiler. The F95 standard
does not prohibit gfortran's current behavior with respect
to \. Therefore, gfortran does not violate the F95 standard.
Craig Dedo
news:DGC1j.18697$Pt.1158@trnddc02...
The point, however, is that there are lots of uses for the backslash
character that conflict with its C-language use as a magic "escape" character
that changes the interpretation of following character(s).
It is quite reasonable for an application written in Fortran to read and/or
write TeX or LaTeX files, PostScript files, or the like. Not to mention that
backslash is the standard directory delimiter in Windows file systems.
A Fortran programmer should not have to take any special action or go
through any extra effort in order to be able to use backslash as an ordinary,
printable character. Anyone who wants to use it as a C-like magic character
should be the person to go to the extra effort.
Steven G. Kargl
"Craig Dedo" <cd...@wi.rr.com> writes:
> "Richard Maine" <nos...@see.signature> wrote in message
> news:1i7zirl.hdl6kepl696lN%nos...@see.signature...
>> Tobias Burnus <bur...@net-b.de> wrote:
>>
>>> I don't know how to handle this best. Backslashes are difficult as
>>> some people expect that "\" prints a backslash, others want to have
>>> "\n" as new line -- and both want to have their choice as default.
>>> With either choice, you have unhappy users. But I am open to
>>> suggestions.
>>
>> Well, in f0003, backslash is part of the standard Fortran character set.
>> So I'll find it awfully hard to accept as reasonable a default that
>> doesn't conform to the standard. But then I'm one of those who has
>> always thought that doing backslash processing on Fortan code was an
>> unreasonable default, so just consider me biased.
>
> standard Fortran character set, the default behavior should be the printable
> character, **NOT** some kind of magic introductory character that transforms the
> interpretation of following character(s). Compiler defaults should always
> follow the Fortran standard, wherever applicable.
gfortran is a Fortran 95 compiler. \ is not a member of the
Fortran character set. See Sec. 3.1.
The Fortran 95 standard does not prohibit the current behavior,
and in fact the very sentence of Sec 3.1 is sufficient to
argue that gfortran's behavior is conforming.
Gordon Sande
The extra effort is in the Fortran source, not the data processed by the
resulting Fortran program.
The question is whether what you think you see when using an "ordinary"
listing program of your Fortran is the same as what the compiler thinks
it sees. The source input to the compiler may choose to treat a "\n"
as a single character. You may not like it, as I do not, but that is the
technical argument that allows it to be standard conforming.
Once it is past the compilers source input mechanism there is no special
treatment. But that treatment is what you normally see and it causes
confusion. The discussionis about the source and not the execution.
Gary Scott
to be interpreted differently. Normal quotes (double or
single/apostrophe) mean literal interpretation. Use some other quoting
scheme to indicate substitution. You could even add an additional
procedure containing text string arguments to substitute.
string = "Literal String" ! A literal string
string = 'Literal String" ! A literal string
call stringargs(["to ","a ","on") !maybe better as an array
string = \"A string \1 perform \2 \n substitution \3."\
So prior to this example, you might call a procedure (stringargs) which
defines the substitution strings for \1, \2, and \3; if undefined,
substitute a null (nothing, effectively delete "\1" from the string).
I don't particularly like "\" and i don't know all the \ formatting
needed for c compatibility if required, I'm thinking \<number> is an
argument to be substituted so maybe those need a different character,
maybe a % or an &.
Need to define whether blank terminates or whether an additional
terminator is required for each argument (\1.) to accommodate spaces.
Of course you can easily write something like this if you need it (i'm
sure it exists in various forms already).
--
Gary Scott
mailto:garylscott@sbcglobal dot net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
Craig Dedo
news:2007112312180316807-gsande@worldnetattnet...
Agreed. However, it is the Fortran programmer who is writing and reading
the Fortran source.
> The question is whether what you think you see when using an "ordinary"
> listing program of your Fortran is the same as what the compiler thinks
> it sees. The source input to the compiler may choose to treat a "\n"
> as a single character. You may not like it, as I do not, but that is the
> technical argument that allows it to be standard conforming.
>
> Once it is past the compilers source input mechanism there is no special
> treatment. But that treatment is what you normally see and it causes
> confusion. The discussionis about the source and not the execution.
I'm not so sure about this. What about the contents of character string
variables? Does a sequence of characters that contains a backslash have the
same semantics in a character variable as it does in a character literal? Or,
does the compiler do some magic transformation of the literal but not the
variable?
FWIW, I would very much like character variables and literals to have the
same semantics, given the same contents.
Consider the following program. Assume Windows-style record termination
(i.e., CRLF combination).
Program Demo_Backslash
Character (Len=132) :: Char_Literal, Char_Variable, Char_Embed_New_Line
Character (Len=2), Parameter :: Char_CRLF = ACHAR(13) // ACHAR(10)
Character (Len=1), Parameter :: Char_Backslash = ACHAR (92)
Char_Embed_New_Line = "Hello, " // Char_CRLF // "world!"
Char_Variable = "Hello, " // Char_Backslash // "nworld!"
Char_Literal = "Hello, \nworld!"
!
! Write each of the three to standard output. Which of the first two does
Char_Literal match?
!
Write (*,*) "Character string with embedded new line:"
Write (*,*) Char_Embed_New_Line
Write (*,*) " "
Write (*,*) "Character string variable:"
Write (*,*) Char_Variable
Write (*,*) " "
Write (*,*) "Character string literal:"
Write (*,*) Char_Literal
End Program Demo_Backslash
Craig Dedo
news:g0E1j.19302$4V6....@newssvr14.news.prodigy.net...
<snip>
> Of course you can easily write something like this if you need it (i'm sure it
> exists in various forms already).
> --
> Gary Scott
> mailto:garylscott@sbcglobal dot net
There already are extensions in some compilers that allow you to specify
C-style escapes without mucking up regular Fortran character literals. See my
comments above. One of them is the Compaq Visual Fortran (CVF) extension that
designates C-style character literals as string contstants followed immediately
by the letter C. Example:
"Character literal \n without embedded new line."
"Character literal \n with embedded new line."C
I believe some other compilers use the same notation or some similar method.
It is my recommendation that gfortran and other Fortran compilers use this
or a similar method to distinguish between regular character literals and those
that have C-style semantics. That way, it is very easy for both the compiler
and human readers to distinguish the two.
Gordon Sande
The source is subject to the magic transformation.
With the possible (very remote!) possibility that one was discussing
some exotic
Fortran interpretive engine where the whole discussion is over how things
are displayed. You are not likely to have one of these drop out of the sky and
hit you on the head. So the realistic practical answer is that this is a
discussion of magical tranformations of the source. The old RTFM tells you
that one any system you will encounter.
> FWIW, I would very much like character variables and literals to
> have the same semantics, given the same contents.
So would a lot of other folks.
Craig Dedo
news:fi6uar$7n4$2...@gnus01.u.washington.edu...
I disagree. \ is not part of the Fortran 95 character set, but it is part
of the Fortran 2003 character set. And almost all Fortran 95 compilers are
adding Fortran 2003 features as soon as resources permit, according to
priorities of customers. It is reasonable to expect that existing F95 compilers
would be consistent with F2003 semantics, except for one of the listed
exceptions in Fortran 2003 1.6.
I disagree with your interpretation of the sentence in question.
Presumably, you mean the very first sentence of 3.1, which reads:
"The processor character set is processor dependent."
I believe that this refers to the contents of the processor character set, not
the semantics of particular characters. E.g., a Fortran compiler on an IBM
mainframe could use EBCDIC as the default character set instead of ASCII.
EBCDIC contains characters that are not in ASCII. In another (hypothetical)
example, a Fortran processor could choose to make its default character set
either ISO 10646 UCS-2 or ISO 10646 UCS-4. No Fortran compiler currently does,
but the rules of 3.1 allow for that.
Starting with Fortran 2003, the Fortran character set includes all of the
printable characters in the ASCII character set, positions 32-126 inclusive.
Section 3.1 in Fortran 2003 is silent about the semantics of the backslash
character. It does not prohibit your interpretation but does not permit it
either. I don't know if there has ever been a formal interpretation request on
this issue.
james...@att.net
> There already are extensions in some compilers that allow you to specify
> C-style escapes without mucking up regular Fortran character literals. See my
> comments above. One of them is the Compaq Visual Fortran (CVF) extension that
> designates C-style character literals as string contstants followed immediately
> by the letter C. Example:
> "Character literal \n without embedded new line."
> "Character literal \n with embedded new line."C
>
> I believe some other compilers use the same notation or some similar method.
These all suffer from a weakness that's shared with
processing the escapes by default: the method is only
applicable to literals. A better solution would be
to have a prefix operator that processes escapes.
"Character literal \n without embedded new line."
.c. "Character result \n with embedded new line."
This has the added bonus of moving the indication to
the left so it's more easily visible. Since it's an
operator you can apply it to string variables, expressions
and so on. So you can write:
.c. ("abc" // '\' // "n" // mystring)
If that's your taste. You could write a different
operator to apply other escapes that some people find
preferable:
.e. "abc ^m^j" // mystring
String literals should be just that: literals. Their
value and their appearance should be one-to-one.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
Dan Nagle
james...@att.net wrote:
> String literals should be just that: literals. Their
> value and their appearance should be one-to-one.
I agree with James Giles here.
The position that backslash escapes are consistent
with the standard seems to me to be based upon two simultaneous
claims:
That the character set is ascii, and
That \ is an escape character.
While possibly defensible by a language lawyer
as just within the bounds of what's allowed,
I'd much prefer to leave such claims to philosophers,
lawyers and monks.
"I can consistently make two contradictory claims provided
I don't make them at the same time."
How 'bout a new intrinsic?
apply_escape( string= ... , escape= ... )
Dick Hendrickson
backslash is not part of the "Fortran character set", but the
"processor character set" in 3.1 also includes option
(2)(e) other characters
3.1.5 says that "additional characters" may appear in comments,
I/O stuff, and character constants.
4.3.2.1 says the characters in a string are numbered and that
the length of a string is the number of characters in it. So,
shouldn't the length of "\n" be 2? If not, what is the \
thing? Is it an "other character" in the sense of 3.1 and 3.1.5?
I think 3.1.5 says you can allow other representable characters
in character constants. And \ is representable in the processor,
otherwise how could you treat "\\" as a single backslash? But,
if \ is a representable other character, then you get the
character length wrong in "\n" if you treat it as an escape
character.
Things could be clearer, but I'd say treating \ as an
escape is non-standard.
Dick Hendrickson
Gary Scott
This implies however that it is a simple C-style string. I want
something more flexible.
--
Gary Scott
mailto:garylscott@sbcglobal dot net
Fortran Library: http://www.fortranlib.com
Craig Dedo
news:bb15322e-3371-4423...@r60g2000hsc.googlegroups.com...
> On Nov 23, 10:42 am, "Craig Dedo" <cd...@wi.rr.com> wrote:
>> There already are extensions in some compilers that allow you to specify
>> C-style escapes without mucking up regular Fortran character literals. See
>> my
>> comments above. One of them is the Compaq Visual Fortran (CVF) extension
>> that
>> designates C-style character literals as string contstants followed
>> immediately
>> by the letter C. Example:
>> "Character literal \n without embedded new line."
>> "Character literal \n with embedded new line."C
>>
>> I believe some other compilers use the same notation or some similar
>> method.
>
> These all suffer from a weakness that's shared with
> processing the escapes by default: the method is only
> applicable to literals. A better solution would be
> to have a prefix operator that processes escapes.
Good idea. I wish I had thought of that.
In addition to the other advantages that you list, anyone can implement this
idea right now. There is no need to wait for a compiler vendor to provide the
functionality. Just write the function to implement the C language substitution
rules and then use the defined-operator feature. Of course, it would be a
user-defined operator rather than an intrinsic operator, but that should not be
much of an inconvenience; defined unary operators have the highest precedence
anyway (Fortran 2003, 7.3, Table 7.7).
Someone should implement this and then post it in this newsgroup. Perhaps I
could do it, time permitting.
> "Character literal \n without embedded new line."
> .c. "Character result \n with embedded new line."
>
> This has the added bonus of moving the indication to
> the left so it's more easily visible. Since it's an
> operator you can apply it to string variables, expressions
> and so on. So you can write:
>
> .c. ("abc" // '\' // "n" // mystring)
>
> If that's your taste. You could write a different
> operator to apply other escapes that some people find
> preferable:
>
> .e. "abc ^m^j" // mystring
>
> String literals should be just that: literals. Their
> value and their appearance should be one-to-one.
>
> --
> J. Giles
--
Gary Scott
> On Nov 23, 10:42 am, "Craig Dedo" <cd...@wi.rr.com> wrote:
>
>> There already are extensions in some compilers that allow you to specify
>>C-style escapes without mucking up regular Fortran character literals. See my
>>comments above. One of them is the Compaq Visual Fortran (CVF) extension that
>>designates C-style character literals as string contstants followed immediately
>>by the letter C. Example:
>> "Character literal \n without embedded new line."
>> "Character literal \n with embedded new line."C
>>
>> I believe some other compilers use the same notation or some similar method.
>
>
>
> These all suffer from a weakness that's shared with
> processing the escapes by default: the method is only
> applicable to literals. A better solution would be
> to have a prefix operator that processes escapes.
>
> "Character literal \n without embedded new line."
> .c. "Character result \n with embedded new line."
that's essentially what I proposed, except rather than a dotted
operator, I just added a "literal" prefix operator ("\"). If this is
the chosen method, ok. I just don't happen to like the .c. notation and
I want it to include substitution in addition to escape sequences:
>
> This has the added bonus of moving the indication to
> the left so it's more easily visible. Since it's an
> operator you can apply it to string variables, expressions
> and so on. So you can write:
>
> .c. ("abc" // '\' // "n" // mystring)
>
> If that's your taste. You could write a different
> operator to apply other escapes that some people find
> preferable:
>
> .e. "abc ^m^j" // mystring
>
> String literals should be just that: literals. Their
> value and their appearance should be one-to-one.
>
> --
> J. Giles
>
> "I conclude that there are two ways of constructing a software
> design: One way is to make it so simple that there are obviously
> no deficiencies and the other way is to make it so complicated
> that there are no obvious deficiencies." -- C. A. R. Hoare
>
>
--
Gary Scott
mailto:garylscott@sbcglobal dot net
Fortran Library: http://www.fortranlib.com
Steven G. Kargl
> of the Fortran 2003 character set. And almost all Fortran 95 compilers are
> adding Fortran 2003 features as soon as resources permit, according to
> priorities of customers. It is reasonable to expect that existing F95 compilers
> would be consistent with F2003 semantics, except for one of the listed
> exceptions in Fortran 2003 1.6.
gfortran is a Fortran 95 compiler. Yes, it is adding F2003 features,
but that does not change the fact that gfortran targets F95.
>
> I disagree with your interpretation of the sentence in question.
> Presumably, you mean the very first sentence of 3.1, which reads:
> "The processor character set is processor dependent."
Yes, I left out the word "first".
> I believe that this refers to the contents of the processor character set, not
> the semantics of particular characters.
The standard does not define the processor character set nor does it
define how those characters are expressed in a text editor. AFAIK,
the backspace character is a single character in the processor
character set. Unfortunately, most text editors require some way
to represent this single character, and gfortran has chosen the
ISO C language method.
I'll also note that gfortran's behavior matches the historical
behavior of g77. The gfortran developers have been take to
task for deviating from g77 behavior.
http://gcc.gnu.org/onlinedocs/gcc-3.3.6/g77/Backslash-in-Constants.html#Backslash-in-Constants
james...@att.net
> jamesgi...@att.net wrote:
> [...] A better solution would be
> > to have a prefix operator that processes escapes.
>
> > "Character literal \n without embedded new line."
> > .c. "Character result \n with embedded new line."
>
> that's essentially what I proposed, except rather than a dotted
> operator, I just added a "literal" prefix operator ("\"). [...]
Except that I couldn't tell what yours was doing. The
syntax combined too many things into one feature. What
is more, you put the \ on both ends like \" ... "\,
sort of like Fortran 90's unpopular array constructors
(/ ... /). That would make your \ a "distfix" operator
and not a prefix operator. Much is written elsewhere
about the negative desirability of distributed fixity.
In any case it still looks like something that applies
only to literals and not to variables, function results,
expressions, or the like.
> [...] If this is
> the chosen method, ok. I just don't happen to like the .c. notation and
> I want it to include substitution in addition to escape sequences:
A couple of years ago I posted to this forum a string
substitution function. It could be redone to allow numbered
patterns instead of replacing in sequence. As it was
written it did:
replace(string, pattern, items)
String was the original, pattern was the thing to be
replaced, and items was an array of values to be included.
So:
replace('abc ^ def ^ ghi ^ end', '^', ['x', 'y'])
would yield "abc x def y ghi ^ end". Note that the
function replaces only as many copies of the pattern
as there are entries in the items array (a general
means of doing "n-ary" operations in Fortran). This
could be modified to expect a number after the pattern.
So a general substitute could be:
subst('abc ^2 def ^1 ghi ^2 end', '^',['x', 'y'])
Which would result in "abc y def x ghi y end". And
any numbered pattern whose number was beyond the number
of items would be nullified. This is already messy
and is the extent of complexity I would ever like to
see in a single feature. In fact, I'm not really happy
with this much complexity.
james...@att.net
...
> How 'bout a new intrinsic?
>
> apply_escape( string= ... , escape= ... )
What would it mean? Is the argument labeled ESCAPE
to be the name of a convention? Or a particular text
pattern (whose meaning is then what?)? There are
several escape conventions. HTML uses one with & prefixes,
so < is the less than symbol (from memory, I think that's
right). Several escape conventions are open-ended so you
can't enumerate all the meanings. Like \0xab is a character
whose position in the collating sequence is hexadecimal ab?
I have no particular objection to a function instead of an
operator. I like the operator a little better in this case
since a quite common operand (a literal) is already delimited,
and the function call syntax adds parenthesis as additional
delimiters. Looks a little busy.
Gary Scott
> On Nov 23, 12:09 pm, Gary Scott <garylsc...@sbcglobal.net> wrote:
>
>>jamesgi...@att.net wrote:
>
>
>>[...] A better solution would be
>>
>>>to have a prefix operator that processes escapes.
>>
>>> "Character literal \n without embedded new line."
>>> .c. "Character result \n with embedded new line."
>>
>>that's essentially what I proposed, except rather than a dotted
>>operator, I just added a "literal" prefix operator ("\"). [...]
>
>
> Except that I couldn't tell what yours was doing. The
> syntax combined too many things into one feature. What
> is more, you put the \ on both ends like \" ... "\,
Yes, I added that later, but didn't originally include the suffixed "\".
I thought of several different prefix characters and decided they all
had some parsing problem and ended up mucking it up. Anyway was, just
trying to illustrate the substitution idea (I'm certain you'd come up
with something better, I just fine this to be a very useful feature).
glen herrmannsfeldt
(snip)
> Just because C uses backslash as a magic introductory character does
> not mean that Fortran should follow that practice. Although some may
> disagree, I have always thought that part of the spirit of Fortran is
> that it is designed to make life easy for the application developer.
> What you write on the blackboard is what you write in the source code.
> Among other things, that means that printable characters are exactly
> that, no more and no less.
It seems that C character string constants are part of Fortran 2003.
ISO_C_BINDING contains a kind parameter C_CHAR that is -1 if the
C_CHAR kind is not supported, or not -1 if it is. If it is not -1,
the C_CHAR kind can be used as a KIND prefix for character constants.
C_CHAR_'\n'
Character constants of non-default KIND are described in 4.4.4.2
including, amazingly enough, a KIND containing Japanese character.
Backslash is part of the Fortran 2003 character set, described
in section 3.1.4.
Table 15.1 describes the specific backslash escape characters
allowed for KIND C_CHAR constants. It seems to me to be a
mistake that no escape for the backslash itself is defined
in table 15.1. That is, C_CHAR_'\\'.
I don't know if Fortran 2003 allows C_CHAR to be the default
KIND for character constants. If so, it would seem that backslash
escapes are allowed. Otherwise, I vote that they not be allowed
by default (but allowed with a compile time option) other than
for constants of the appropriate KIND.
-- glen
Dan Nagle
glen herrmannsfeldt wrote:
> ISO_C_BINDING contains a kind parameter C_CHAR that is -1 if the
> C_CHAR kind is not supported, or not -1 if it is. If it is not -1,
> the C_CHAR kind can be used as a KIND prefix for character constants.
>
> C_CHAR_'\n'
But does the C kind change the meaning of the literal?
That is, both the C compiler and the Fortran compiler
likely support ascii as their character type.
It is far better to use the c_null_char, c_alert, etc
when c_char /= -1.
Richard Maine
> Table 15.1 describes the specific backslash escape characters
> allowed for KIND C_CHAR constants.
It does not. Reread what the text says about the table rather than
trying to look at the table and guess what it means. This table has
absolutely zero to do with the syntax of literal constants. The table is
giving the values of several named constants and is using the c syntax
to denote the value. That is only how the value is indicated in this
table. It has nothing at all to do with any Fortran syntax.
> I don't know if Fortran 2003 allows C_CHAR to be the default
> KIND for character constants.
It not only allows it, I'd expect that to be the almost universal case.
> If so, it would seem that backslash
> escapes are allowed.
No. That is based on your misinterpretation of the table. Furthermore,
even if your misreading were correct, that would not imply that such
escapes are allowed, insomuch as that would directly contradict the
definition of literal constant syntax elsewhere. That would just imply
that the standard was self-contradictory. But it doesn't say that.
james...@att.net
...
> ISO_C_BINDING contains a kind parameter C_CHAR that is -1 if the
> C_CHAR kind is not supported, or not -1 if it is. If it is not -1,
> the C_CHAR kind can be used as a KIND prefix for character constants.
>
> C_CHAR_'\n'
That's not what the standard document says. It says that
if the value of C_CHAR is not -1 the entries in table 15.1
are given using C syntax. It doesn't say that Fortran processors
will use that same syntax. The named quantities on the left
of table 15.1 are the corresponding Fortran syntax for those
values.
Thomas Koenig
> Well, in f0003, backslash is part of the standard Fortran character set.
> So I'll find it awfully hard to accept as reasonable a default that
> doesn't conform to the standard. But then I'm one of those who has
> always thought that doing backslash processing on Fortan code was an
> unreasonable default, so just consider me biased.
gfortran currently follows g77 in this respect. The g77 rationale
can be found at
http://gcc.gnu.org/onlinedocs/gcc-3.3.6/g77/Backslash-in-Constants.html#Backslash-in-Constants
(basically, compatibility with existing f77 compilers at the time).
How do other existing compilers treat backslashes? It would be
interesting to know if g77/gfortran are alone in this.
glen herrmannsfeldt
> glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>>Table 15.1 describes the specific backslash escape characters
>>allowed for KIND C_CHAR constants.
> It does not. Reread what the text says about the table rather than
> trying to look at the table and guess what it means. This table has
> absolutely zero to do with the syntax of literal constants. The table is
> giving the values of several named constants and is using the c syntax
> to denote the value. That is only how the value is indicated in this
> table. It has nothing at all to do with any Fortran syntax.
I am not sure that is any better. Note that the given constants
are type int in C, not char. (Just to be confusing, they are
char in C++.)
In any case, it does not seem unreasonable to me for constants
of explicit kind C_CHAR to contain C escapes, even if the
standard doesn't currently indicate that. That seems consistent
with allowing Japanese characters in NIHONGO kind constants.
>>I don't know if Fortran 2003 allows C_CHAR to be the default
>>KIND for character constants.
> It not only allows it, I'd expect that to be the almost universal case.
-- glen
Dan Nagle
glen herrmannsfeldt wrote:
> In any case, it does not seem unreasonable to me for constants
> of explicit kind C_CHAR to contain C escapes, even if the
> standard doesn't currently indicate that.
Suppose c_char = 1, and selected_char_kind( 'ascii') = 1.
What is 1_'\n' ?
Richard Maine
> In any case, it does not seem unreasonable to me for constants
> of explicit kind C_CHAR to contain C escapes, even if the
> standard doesn't currently indicate that.
It is rather more than that the standard "doesn't currently indicate
that." Instead, that would specifically contradict the standard.
One can make pedantic arguments to justify c escapes as being
standard-conforming by noting that the standard doesn't specify the
representation of source code. But such arguments are pretty weak and
have much of the flavor of rationalization of a desired result. I
somewhat doubt that any of the implementations actually act exactly as
would be implied by really following that argument literally. (For
example, do they get column numbers "right" in contexts where it
matters?) Instead, they just pass that off as an excuse without actually
meaning it as anything else.
If one processed the escapes only in literal strings, then that would
pretty much negate the whole underpinning of the rationalization.
You can, of course, consider whatever you want to be reasonable. You can
consider it reasonable to violate any part of the standard that you
don't like. I won't argue the point. I will point out that it does
violate the standard.
James Van Buskirk
news:47472586$0$4966$4c36...@roadrunner.com...
> In addition to the other advantages that you list, anyone can implement
> this idea right now. There is no need to wait for a compiler vendor to
> provide the functionality. Just write the function to implement the C
> language substitution rules and then use the defined-operator feature. Of
> course, it would be a user-defined operator rather than an intrinsic
> operator, but that should not be much of an inconvenience; defined unary
> operators have the highest precedence anyway (Fortran 2003, 7.3, Table
> 7.7).
> Someone should implement this and then post it in this newsgroup.
> Perhaps I could do it, time permitting.
Well, not quite. Having high priority is normally undesirable I
think, but of course we could always use parentheses. Let's see...
we have to change '\a' to achar(7), '\b' to achar(8), '\f' to achar(12),
'\n' to achar(10), '\r' to achar(13), '\t' to achar(9), '\v' to achar(11),
"\'" to achar(39), '\"' to achar(34), '\\' to achar(92), '\?' to achar(63)
and all that, but also '\1' to achar(1), '\12' to achar(10) and
'\123' to achar(83). Also, achar(92)//achar(10) translates to ''.
Microsoft says that '\c' should translate to 'c' but gfortran would
translate it to '\c'.
http://msdn2.microsoft.com/en-us/library/h21280bw(VS.80).aspx
Translate '\x12' obviously to achar(18), but does that mean
'\x1' becomes achar(1)? How about '\x123' or '\x'? These seem
to not be unambiguously defined.
A problem with a user-defined function is the translation of
'\"' and "\'". These can't both be trapped in the same string
without compiler assistance. In a C program most of the
escape sequences are '\n' which is irrelevant in record-oriented
Fortran I/O. Also, do you want to trim the output of the
function to take into account the string contraction? Easily
done with a specification function, but it would stop the
function from being elemental. Do you want to append the
achar(0) at the end as well? Probably not, because I don't
think existing implementations do so.
Even C compilers implement these escape sequences differently.
Therefore anyone who uses them in C has to be ready to change
his escape sequences around as the program is ported to different
compilers. Changing them to invocations of ACHAR is then just
as normal as would be the case in changing C compilers.
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
Craig Dedo
news:Dq2dnca0_tpIQNra...@comcast.com...
> "Craig Dedo" <cd...@wi.rr.com> wrote in message
> news:47472586$0$4966$4c36...@roadrunner.com...
>
>> In addition to the other advantages that you list, anyone can implement
>> this idea right now. There is no need to wait for a compiler vendor to
>> provide the functionality. Just write the function to implement the C
>> language substitution rules and then use the defined-operator feature. Of
>> course, it would be a user-defined operator rather than an intrinsic
>> operator, but that should not be much of an inconvenience; defined unary
>> operators have the highest precedence anyway (Fortran 2003, 7.3, Table 7.7).
>
>> Someone should implement this and then post it in this newsgroup. Perhaps
>> I could do it, time permitting.
>
> Well, not quite. Having high priority is normally undesirable I
> think, but of course we could always use parentheses. Let's see...
Thanks for pointing out the complications, but I believe that all or nearly
all of them are already covered by the C 99 Standard, ISO/IEC 9899:1999,
especially section 6.4.4.4.
> we have to change '\a' to achar(7), '\b' to achar(8), '\f' to achar(12),
> '\n' to achar(10), '\r' to achar(13), '\t' to achar(9), '\v' to achar(11),
> "\'" to achar(39), '\"' to achar(34), '\\' to achar(92), '\?' to achar(63)
> and all that, but also '\1' to achar(1), '\12' to achar(10) and
> '\123' to achar(83). Also, achar(92)//achar(10) translates to ''.
All of these are covered by C99, 6.4.4.4.
> Microsoft says that '\c' should translate to 'c' but gfortran would
> translate it to '\c'.
> http://msdn2.microsoft.com/en-us/library/h21280bw(VS.80).aspx
This behavior is Microsoft specific and is labelled as such on the web page
you reference. It is most definitely non-standard. See C99, 6.4.4.4, par. 8
and note 64. In fact, note 64 requires an error condition if there is any
escape sequence that is not covered by any of the specifically authorized
translations.
> Translate '\x12' obviously to achar(18), but does that mean
> '\x1' becomes achar(1)? How about '\x123' or '\x'? These seem
> to not be unambiguously defined.
These are covered by C99, 6.4.4.4, especially par. 1, 5, 6, 7, and 9.
> A problem with a user-defined function is the translation of
> '\"' and "\'". These can't both be trapped in the same string
> without compiler assistance. In a C program most of the
> escape sequences are '\n' which is irrelevant in record-oriented
> Fortran I/O. Also, do you want to trim the output of the
> function to take into account the string contraction? Easily
> done with a specification function, but it would stop the
> function from being elemental.
I had not thought about the elemental issue before, but making it elemental
seems reasonable. It would add useful functionality at next to no cost. Blank
padding at the end is not a big deal in Fortran.
> Do you want to append the
> achar(0) at the end as well? Probably not, because I don't
> think existing implementations do so.
I was not planning to add a null character at the end. FWIW, the CVF
extension does add a null character at the end, according to the documentation.
I have not looked at such strings in the debugger, but, in my experience, DEC,
CVF, HP, and Intel documentation is highly accurate.
> Even C compilers implement these escape sequences differently.
> Therefore anyone who uses them in C has to be ready to change
> his escape sequences around as the program is ported to different
> compilers. Changing them to invocations of ACHAR is then just
> as normal as would be the case in changing C compilers.
If I did it, I would follow the C99 standard rigorously and not worry about
compiler-specific deviations from C99. That is the only way to keep the
implementation effort to a reasonable amount.
t...@lecwireless.com
> Tobias Burnus <bur...@net-b.de> wrote:
> > I don't know how to handle this best. Backslashes are difficult as
> > some people expect that "\" prints a backslash, others want to have
> > "\n" as new line -- and both want to have their choice as default.
> > With either choice, you have unhappy users. But I am open to
> > suggestions.
>
> So I'll find it awfully hard to accept as reasonable a default that
> doesn't conform to the standard. But then I'm one of those who has
> always thought that doing backslash processing on Fortan code was an
> unreasonable default, so just consider me biased.
>
> Richard Maine | Good judgement comes from experience;
> email: last name at domain . net | experience comes from bad judgement.
> domain: summertriangle | -- Mark Twain
What he said.
glen herrmannsfeldt
(snip)
> Well, not quite. Having high priority is normally undesirable I
> think, but of course we could always use parentheses. Let's see...
> we have to change '\a' to achar(7), '\b' to achar(8), '\f' to achar(12),
> '\n' to achar(10), '\r' to achar(13), '\t' to achar(9), '\v' to achar(11),
> "\'" to achar(39), '\"' to achar(34), '\\' to achar(92), '\?' to achar(63)
> and all that, but also '\1' to achar(1), '\12' to achar(10) and
> '\123' to achar(83). Also, achar(92)//achar(10) translates to ''.
> Microsoft says that '\c' should translate to 'c' but gfortran would
> translate it to '\c'.
K&R2, and I believe C89, leave these undefined. Many C compilers
generate them as 'c'.
> http://msdn2.microsoft.com/en-us/library/h21280bw(VS.80).aspx
> Translate '\x12' obviously to achar(18), but does that mean
> '\x1' becomes achar(1)? How about '\x123' or '\x'? These seem
> to not be unambiguously defined.
Most that I know of allow one, two, or three octal digits and
two hex digits. K&R2 says "There is no limit on the number of
digits, but the behavior is undefined if the resulting character
value exceeds that of the largest character." (This could be
interesting on systems with char larger than eight bits.)
--------------------------------
I suppose I don't see anything wrong with doing it as a function,
though I have never seen that done in C. In C, they are by
definition done to character constants allowing one to put
in characters that would otherwise be difficult.
As a side note, Java has unicode escapes of the form \uXXXX
where XXXX is four hex digits. These escapes are processed
earlier than string escapes, such that a line like:
s="some string\u000a";
will fail with an unterminated string, though
s="another string\u0022;
will work fine.
(snip)
> Even C compilers implement these escape sequences differently.
How are they different? The single character escapes should work
the same on all systems. The octal and hex escapes, if followed
by an octal or hex digit, could be done differently I suppose.
> Therefore anyone who uses them in C has to be ready to change
> his escape sequences around as the program is ported to different
> compilers. Changing them to invocations of ACHAR is then just
> as normal as would be the case in changing C compilers.
Do you have any examples that were done differently?
-- glen
Gary Scott
FWIW ""C is a microsoft Fortran extension rather than a CVF originated one.
>
>> Even C compilers implement these escape sequences differently.
>> Therefore anyone who uses them in C has to be ready to change
>> his escape sequences around as the program is ported to different
>> compilers. Changing them to invocations of ACHAR is then just
>> as normal as would be the case in changing C compilers.
>
>
> If I did it, I would follow the C99 standard rigorously and not worry
> about compiler-specific deviations from C99. That is the only way to
> keep the implementation effort to a reasonable amount.
>
--
Gary Scott
mailto:garylscott@sbcglobal dot net
Fortran Library: http://www.fortranlib.com
Gary Scott
None of these proposals seem to address a generic substitution
capability. That's far more broadly useful than simple escape sequences.
james...@att.net
I tend to disagree with both the idea of making the
operator elemental and with leaving the null off the
end. The latter will almost certainly confuse those
that expect the operation to work for c interop.
The former requires more of those unfortunate pad
blanks. With the advent of f2003 and genuinely
variable length strings having operations that
blank pad independently of the assignment operation
will not seem particularly desirable. Being able
to distinguish genuinely significant trailing blanks
from padding is something I need much more often than
elemental operation.
james...@att.net
...
> None of these proposals seem to address a generic substitution
> capability. That's far more broadly useful than simple escape sequences.
Substitution is also a completely different operation and
should be a separate feature from processing escapes.
Gary Scott
> On Nov 24, 9:48 am, Gary Scott <garylsc...@sbcglobal.net> wrote:
> ...
>
>
>>None of these proposals seem to address a generic substitution
>>capability. That's far more broadly useful than simple escape sequences.
>
>
> Substitution is also a completely different operation and
> should be a separate feature from processing escapes.
In practice, it's virtually indistinguishable. Escape processing IS
substitution.
>
> --
> J. Giles
>
> "I conclude that there are two ways of constructing a software
> design: One way is to make it so simple that there are obviously
> no deficiencies and the other way is to make it so complicated
> that there are no obvious deficiencies." -- C. A. R. Hoare
Craig Dedo
news:S7ydnVZGcPbCzdXa...@comcast.com...
>
> As a side note, Java has unicode escapes of the form \uXXXX
> where XXXX is four hex digits. These escapes are processed
> earlier than string escapes, such that a line like:
>
> s="some string\u000a";
>
> will fail with an unterminated string, though
>
> s="another string\u0022;
>
> will work fine.
>
>
> -- glen
This feature is actually part of C++ 98 (ISO/IEC 14882:1998) and C99
(ISO/IEC 9899:1999) also. Both standards allow four and eight digit hex codes
to specify ISO 10646 (aka Unicode) characters of the form:
\unnnn and
\Unnnnnnnn
The lowercase version designates one hex quad while the uppercase version
designates two hex quads.
References: C++ 98, 2.2 and C99 6.4.3
james...@att.net
> jamesgi...@att.net wrote:
> > On Nov 24, 9:48 am, Gary Scott <garylsc...@sbcglobal.net> wrote:
> > ...
>
> >>None of these proposals seem to address a generic substitution
> >>capability. That's far more broadly useful than simple escape sequences.
>
> > Substitution is also a completely different operation and
> > should be a separate feature from processing escapes.
>
> In practice, it's virtually indistinguishable. Escape processing IS
> substitution.
Operationally they are not very similar at all. Escape
handling is a set of predefined transformations and needs
only one operand: the string to be processed. General
substitution requires at least three arguments: the string
to be processed, the pattern(s) to be replaced, and the
value(s) that replace those pattern(s). One can be done
as a prefix operator. The other can't be done as an
operator at all.
By your logic, *ALL* processing is simply an example of
general substitution: you change the program's input into
some different output.
James Van Buskirk
> If I did it, I would follow the C99 standard rigorously and not worry
> about compiler-specific deviations from C99. That is the only way to keep
> the implementation effort to a reasonable amount.
It occurred to me that a non-intrinsic implementation could not function
in the context of an initialization expression.
james...@att.net
...
> It occurred to me that a non-intrinsic implementation could not function
> in the context of an initialization expression.
In the dim past I recommended that such an operator be made
intrinsic (maybe directly, maybe as part of the ISO_C_BINDING
intrinsic module). Deaf ears at the time.
Gary Scott
> On Nov 24, 12:09 pm, Gary Scott <garylsc...@sbcglobal.net> wrote:
>
>>jamesgi...@att.net wrote:
>>
>>>On Nov 24, 9:48 am, Gary Scott <garylsc...@sbcglobal.net> wrote:
>>>...
>>
>>>>None of these proposals seem to address a generic substitution
>>>>capability. That's far more broadly useful than simple escape sequences.
>>
>>>Substitution is also a completely different operation and
>>>should be a separate feature from processing escapes.
>>
>>In practice, it's virtually indistinguishable. Escape processing IS
>>substitution.
>
>
> Operationally they are not very similar at all. Escape
> handling is a set of predefined transformations and needs
> only one operand: the string to be processed. General
> substitution requires at least three arguments: the string
> to be processed, the pattern(s) to be replaced, and the
> value(s) that replace those pattern(s). One can be done
> as a prefix operator. The other can't be done as an
> operator at all.
>
> By your logic, *ALL* processing is simply an example of
> general substitution: you change the program's input into
> some different output.
The substitution I'm referring to only applies to the token that is
inserted into the literal string, exactly the same as an escape sequence
is inserted. If you want to define some more sophisticated substitution
process, that's fine by me, but I would be fine with a minor extension
to the escape substitution being proposed.
%1 = "is"
i.e. "the string %1 short"
would result in a simple substitution of "is" in place of %1. That is
similar to the way an escape sequence is substituted:
"the string \n short"
results in a particular ascii character being substituted in place of "\n".
or I could:
%1 = "\n"
"the string %1 short"
would perhaps substitute a literal string "\n" in the string
something more sophisticated is welcome by me. I'd prefer not to have
to use a .x. operator but I can live with it.
>
> --
> J. Giles
>
> "I conclude that there are two ways of constructing a software
> design: One way is to make it so simple that there are obviously
> no deficiencies and the other way is to make it so complicated
> that there are no obvious deficiencies." -- C. A. R. Hoare
james...@att.net
...
> The substitution I'm referring to only applies to the token that is
> inserted into the literal string, exactly the same as an escape sequence
> is inserted. If you want to define some more sophisticated substitution
> process, that's fine by me, but I would be fine with a minor extension
> to the escape substitution being proposed.
>
> %1 = "is"
A whole new class of identifier is "a minor extension"?
> i.e. "the string %1 short"
So, string "literals" are not only *not* literal (meaning
the same as their appearance) but aren't even compile-time
constants anymore? And that's "a minor extension"?
I use substitution functions all the time. I almost never
do escape sequences. I use backslash extensively (and not
for escapes). For the text substitution feature to *also*
do escape sequence processing would seem to me a *very*
unfriendly act. It would essentially make the feature
completely useless.
glen herrmannsfeldt
> On Nov 24, 4:27 pm, Gary Scott <garylsc...@sbcglobal.net> wrote:
>>The substitution I'm referring to only applies to the token that is
>>inserted into the literal string, exactly the same as an escape sequence
>>is inserted. If you want to define some more sophisticated substitution
>> process, that's fine by me, but I would be fine with a minor extension
>>to the escape substitution being proposed.
>>%1 = "is"
> A whole new class of identifier is "a minor extension"?
>>i.e. "the string %1 short"
> So, string "literals" are not only *not* literal (meaning
> the same as their appearance) but aren't even compile-time
> constants anymore? And that's "a minor extension"?
My understanding is that he means a compile time substitution.
That is, the % variables are compile time variables.
The PL/I preprocessors has compile time variables, I don't remember
if it does substitution inside string constants. One of the old
favorites is unrolling a loop:
%do i=1 to 10;
a(i)=b(i)*c(i);
%end;
will compile to 10 assignment statements.
-- glen
Gary Scott
> james...@att.net wrote:
>
>> On Nov 24, 4:27 pm, Gary Scott <garylsc...@sbcglobal.net> wrote:
>
>
>>> The substitution I'm referring to only applies to the token that is
>>> inserted into the literal string, exactly the same as an escape sequence
>>> is inserted. If you want to define some more sophisticated substitution
>>> process, that's fine by me, but I would be fine with a minor extension
>>> to the escape substitution being proposed.
>
>
>>> %1 = "is"
>
>
>> A whole new class of identifier is "a minor extension"?
>
>
>>> i.e. "the string %1 short"
>
>
>> So, string "literals" are not only *not* literal (meaning
>> the same as their appearance) but aren't even compile-time
>> constants anymore? And that's "a minor extension"?
Fairly minor, you still have existing literals processed exactly as
expected. Special processing only by application of special syntax.
>
>
> My understanding is that he means a compile time substitution.
> That is, the % variables are compile time variables.
>
> The PL/I preprocessors has compile time variables, I don't remember
> if it does substitution inside string constants. One of the old
> favorites is unrolling a loop:
>
> %do i=1 to 10;
> a(i)=b(i)*c(i);
> %end;
>
> will compile to 10 assignment statements.
>
> -- glen
>
I wasn't intending to limit to compile time only. This type of
substitution already exists in many products I use. It is extremely
useful. Yes, it would require some run-time support. Come on guys,
show a little imagination.
glen herrmannsfeldt
(snip)
>>>> %1 = "is"
>>>> i.e. "the string %1 short"
(I wrote)
>> My understanding is that he means a compile time substitution.
>> That is, the % variables are compile time variables.
>> The PL/I preprocessors has compile time variables,
(snip)
> I wasn't intending to limit to compile time only. This type of
> substitution already exists in many products I use. It is extremely
> useful. Yes, it would require some run-time support. Come on guys,
> show a little imagination.
How does the system know which one is a variable and which is not?
Some interpreted languages do recognize variable names in some
contexts like this at run time. Compiled languages most of
the time don't. (NAMELIST and PL/I's GET DATA being exceptions.)
Otherwise, many string substitution problems are pretty easy
with a regular expression package to recognize them and indicate
the place to do the substitution.
-- glen
-- glen
Dan Nagle
Gary Scott wrote:
> glen herrmannsfeldt wrote:
>
>> james...@att.net wrote:
>>> So, string "literals" are not only *not* literal (meaning
>>> the same as their appearance) but aren't even compile-time
>>> constants anymore? And that's "a minor extension"?
>
> Fairly minor, you still have existing literals processed exactly as
> expected. Special processing only by application of special syntax.
I think control characters and graphic characters are rather different.
Graphic characters may be displayed via a single graphic in source text.
Control characters cannot. Being capable of being a part of source code
in a one-to-one way, seems to me to be fairly fundamental.
A general substitution procedure means to take one set of graphic
characters and replace them by another set of graphic characters
when they appear in a third set of graphic characters. That's rather
different from processing control characters.
Fortran doesn't handle control characters in any systematic way.
I think that's a shortcoming of Fortran, but I've lost that battle
every time I've tried to do something about it.
> I wasn't intending to limit to compile time only. This type of
> substitution already exists in many products I use. It is extremely
> useful. Yes, it would require some run-time support. Come on guys,
> show a little imagination.
A programmer may already use the c_<cc> (where <cc> names a control
character) constants. They may be used to insert the most frequently
used control characters into graphic strings as needed.
Defining a new category of character is a major undertaking,
it's not a matter of a lack of imagination. And a proposed syntax
doesn't change that. What, exactly, are the semantics to be supported
by the proposed syntax? That is, what, exactly are the semantics
of the new category of character?
Gary Scott
proposed does not alter existing fixed length strings or literals in any
way.
Dan Nagle
Gary Scott wrote:
> Boy, I'm not sure why people are going so far off in the weeds. What I
> proposed does not alter existing fixed length strings or literals in any
> way.
AIUI, your proposal altered existing character literals in two ways:
One graphic character had a new meaning; and
The length of the literal is no longer the number of graphic characters
in it.
AIUI, your proposal altered fixed length character strings by allowing
a longer literal to be entirely contained within the string.
Am I so far off in the weeds?
Gary Scott
It merely provided a static template which exists as a fixed length
string. It is treated exactly as a fixed length string except when
alternate processing is explicitly applied. Post processing performs
the substitution for both "escape" sequences or the generic string
substitutions. Could be done at compile time as well as run time.
John Harper
>> backslashes which work out of the box with all compilers.
>
>Well, all standard-conforming compilers. I seem to recall that F doesn't
>like achar. I might have gotten that confused, as I don't use F, but I
>remember something like that at one time.
In PGPLOT the backslash is used for various purposes such as \d to lower
and \u to raise the following text. In f77 I had to write one of
CALL PGTEXT(x,y,'Water is H\d2\uO')
CALL PGTEXT(x,y,'Water is H\\d2\\uO')
to put some text on a graph at the coodinates x,y, and remember which
form to use with which compiler, until I found this on a g77 web page:
CHARACTER backsl*1
PARAMETER(backsl='\\')
Then f77 and f95 compilers of either backslash-kind are happy with
CALL PGTEXT(x,y,'Water is H'//backsl//'d2'//backsl//'uO')
-- John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail john....@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045
Wade Ward
> "James Van Buskirk" <not_...@comcast.net> wrote in message
>> Even C compilers implement these escape sequences differently.
>> Therefore anyone who uses them in C has to be ready to change
>> his escape sequences around as the program is ported to different
>> compilers. Changing them to invocations of ACHAR is then just
>> as normal as would be the case in changing C compilers.
>
> If I did it, I would follow the C99 standard rigorously and not worry
> about compiler-specific deviations from C99. That is the only way to keep
> the implementation effort to a reasonable amount.
This sounds good on paper, but might be less good in practice.
You'd be wrong to think C99 were popular in the C crowd. I like it, but I'm
very much the exception. Furthermore, I'm not in the C crowd.
--
wade ward
wa...@zaxfuuq.net
435 -838-7760
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Craig Dedo
news:1196059...@sp12lax.superfeed.net...
>
> "Craig Dedo" <cd...@wi.rr.com> wrote in message
> news:47483745$0$24334$4c36...@roadrunner.com...
>> "James Van Buskirk" <not_...@comcast.net> wrote in message
>
>>> Even C compilers implement these escape sequences differently.
>>> Therefore anyone who uses them in C has to be ready to change
>>> his escape sequences around as the program is ported to different
>>> compilers. Changing them to invocations of ACHAR is then just
>>> as normal as would be the case in changing C compilers.
>>
>> If I did it, I would follow the C99 standard rigorously and not worry
>> about compiler-specific deviations from C99. That is the only way to keep
>> the implementation effort to a reasonable amount.
> This sounds good on paper, but might be less good in practice.
>
> You'd be wrong to think C99 were popular in the C crowd. I like it, but I'm
> very much the exception. Furthermore, I'm not in the C crowd.
> --
> wade ward
>
> wa...@zaxfuuq.net
> 435 -838-7760
I believe that your reasoning is faulty on a number of points.
1. In my experience, doing C language programming professionally for over
10 years in commercial environments with real profit-and-loss responsibility,
the software developers take the relevant language standards very seriously.
This includes the ISO C and C++ standards. If the compiler does not support a
particular feature that is in a standard, the expectation is that the developer
of the compiler is actively working to develop that feature for a future
version.
Of course, I am well aware that some C and C++ developers have the attitude
that whatever Emperor Bill decrees is the standard. I can't do anything about
that except to point out to such people that the ISO is the world's official
standards body.
BTW, if you want a real entertainment, #include all of the header files
defined in the C99 standard and use some of those features in the "Hello,
World!" program and try to compile it with MS VC++. Almost certainly, it will
fail, due to the use of unsupported features. Let's see, C99 has been out for
nearly 8 years now. Why is that?
2. I would write such a function for Fortran programmers, not C
programmers. The purpose would be to provide a way to allow the processing of C
language escape sequences while still preserving the integrity of the semantic
interpretation of Fortran character expressions.
C and C++ language bigots do not use Fortran, except under duress.
Professional software developers respect the standards and conventions of the
languages, operating systems, and other tools that they work with. Respect for
such standards and conventions is part of being a professional. Even if a
professional software developer has a strong preference for C or C++, he or she
will respect the standards and conventions of Fortran when programming in
Fortran.
3. If I developed such a function, I would need an objective, impartial
reference framework. The current ISO standard is the best such reference.
4. Technically speaking, any compiler deviations from the provisions of the
C99 standard are non-standard. They cannot be standard-conforming extensions.
This is because the C99 standard requires the compiler to generate an exception
condition if it encounters any escape sequence that is not defined in the C99
standard. I pointed this out in an earlier message in this thread. There is no
flexibility regarding additional escape sequences beyond those defined in the
C99 standard.
mike....@noaa.gov
> On 2007-11-22, Richard Maine <nos...@see.signature> wrote:
>
> > Well, in f0003,backslashis part of the standard Fortran character set.
> > So I'll find it awfully hard to accept as reasonable a default that
> > doesn't conform to the standard. But then I'm one of those who has
> > unreasonable default, so just consider me biased.
>
> can be found at
>
> http://gcc.gnu.org/onlinedocs/gcc-3.3.6/g77/Backslash-in-Constants.ht...
>
> (basically, compatibility with existing f77 compilers at the time).
>
> How do other existing compilers treat backslashes? It would be
> interesting to know if g77/gfortran are alone in this.
I tried it on Windows XP with Lahey (LF95 7.10.02), g95
(0.91!), and Intel fortran (ifort 10.0.026). They all accept the
backslash as a character in a quoted string, and when asked to
print it, they print it. No special setting were used.
I would far prefer that the default of *any* compiler be not to apply
any special translation to visible characters the user has typed.
Clearly OSes have different line end characters, and it is reasonable
for compilers to respect that. It is not reasonable for compilers to
impose a peculiar translation of a visible character, just because one
operating system happens to do that.
The above of course is a matter of taste. What goes beyond taste
is the F2003 standard. Given that the backslash is part of the
character set, it arguably would be a defect for a compiler by
default to mess with the user's input of printable characters.
--
Mike Prager, NOAA, Beaufort, NC
* Opinions expressed are personal and not represented otherwise.
* Any use of tradenames does not constitute a NOAA endorsement.
Gary Scott
Absolutely agree. Any translation must be by specific request of the
application programmer.
>
> --
> Mike Prager, NOAA, Beaufort, NC
> * Opinions expressed are personal and not represented otherwise.
> * Any use of tradenames does not constitute a NOAA endorsement.
Craig Dedo
news:IMB2j.65863$RX.5...@newssvr11.news.prodigy.net...
FWIW, I tried it using CVF 6.6.C, Lahey LF95 5.6, Silverfrost FTN95 5.10,
and G95 0.91. All of them interpret the backslash as a printable character,
**NOT** as an introduction to C-style escape sequences. Only GFortran 4.3.0 by
default interprets the backslash as an introduction to a C-style escape
sequence.
I agree with both Mike Prager and Gary Scott for the reasons that they
mention. Since backslash is a printable character in the Fortran charactder set
in Fortran 2003, any other interpretation of backslash violates section 1.5,
"Conformance", of the Fortran standard. The following sentence from Fortran
2003 1.5, paragraph 4 [2:35-36], is particularly relevant:
"A standard-conforming processor may allow additional forms and relationships
provided that such additional forms and relationships do not conflict with the
standard forms and relationships."
This language is unchanged from Fortran 95.
FWIW, the same idea is expressed in different language in C99, 4, par. 6 and
C++ 98, 1.4, par. 8.
Steven G. Kargl
"Craig Dedo" <cd...@wi.rr.com> writes:
>
> I agree with both Mike Prager and Gary Scott for the reasons that they
> mention. Since backslash is a printable character in the Fortran charactder set
> in Fortran 2003, any other interpretation of backslash violates section 1.5,
> "Conformance", of the Fortran standard. The following sentence from Fortran
> 2003 1.5, paragraph 4 [2:35-36], is particularly relevant:
>
Which is completely and utterly irrelevant for a Fortran
95 compiler where backslash is not a member of the Fortran
character set. There is an enormous difference between a
Fortran 95 compiler that offers a few Fortran 2003 features
and a Fortran 2003 compiler that is missing a few features.
> "A standard-conforming processor may allow additional forms and relationships
> provided that such additional forms and relationships do not conflict with the
> standard forms and relationships."
According to the above sentence, gfortran is a conforming Fortran 95
compiler because, well surprise, backslash is not a member of the
Fortran character set.
FWIW, the gfortran developers appear to be on the verge of
changing the default behavior for the 4.3.0 release. However,
this change will not suddenly give gfortran conformance to
Fortran 2003's Fortran character set.
Dick Hendrickson
> In article <474b004d$0$8877$4c36...@roadrunner.com>,
> "Craig Dedo" <cd...@wi.rr.com> writes:
>> I agree with both Mike Prager and Gary Scott for the reasons that they
>> mention. Since backslash is a printable character in the Fortran charactder set
>> in Fortran 2003, any other interpretation of backslash violates section 1.5,
>> "Conformance", of the Fortran standard. The following sentence from Fortran
>> 2003 1.5, paragraph 4 [2:35-36], is particularly relevant:
>>
>
> Which is completely and utterly irrelevant for a Fortran
> 95 compiler where backslash is not a member of the Fortran
> character set. There is an enormous difference between a
> Fortran 95 compiler that offers a few Fortran 2003 features
> and a Fortran 2003 compiler that is missing a few features.
>
>> "A standard-conforming processor may allow additional forms and relationships
>> provided that such additional forms and relationships do not conflict with the
>> standard forms and relationships."
>
> According to the above sentence, gfortran is a conforming Fortran 95
> compiler because, well surprise, backslash is not a member of the
> Fortran character set.
As I said before, it's the PROCESSOR character set, not the Fortran
character set, that's the interesting thing for character constants.
3.1 is clear that the processor character set includes the
[possibly empty] set of "other characters" and the Fortran
character set.
3.1.5 is clear that additional characters may be representable
and, if they are, they can appear in character constants.
4.3.2.1 says the length of a character string is the number of
characters in it.
So, what does gfortran do with "\\"? I think most compilers that
treat a \ as an escape treat "\\" as if it were "\". But, isn't that
non-conforming? If you can have a \ in a string (no matter how you
represent it) doesn't it have to be a representable character?
and then doesn't the length of "\\" have to be 2?
Dick Hendrickson
Michael Prager
> According to the above sentence, gfortran is a conforming Fortran 95
> compiler because, well surprise, backslash is not a member of the
> Fortran character set.
I won't debate that point. The point I will debate is that Unix
is the "mother" operating system whose quirks should be the
default everywhere. There is no reason to take an arbitrary
printing character and turn it by default into an escape, other
than mimicking C and Unix.
Of course Unix and its love children have contributed
considerably to computing. I just don't think everything in
computing should be bound to Unix ways of doing things.
Mike
(who has used at least a dozen operating systems)
--
Mike Prager, NOAA, Beaufort, NC
Address spam-trapped; remove color to reply.
Steven G. Kargl
How so?
> If you can have a \ in a string (no matter how you
> represent it) doesn't it have to be a representable character?
AFAICT, the F95 standard doesn't address how one expresses
the representable backslash character in a text file. Section
14.6.3.1 declares that a "nonpointer scalar object of type
default character and character length one occupies a one
character storage unit". The standard does not address how
one puts a new line or back space or other character into a
a single storage unit. One might even argue that Sec. 1.4(1)
allows the transformation of "\\" into \ or "\n" into the
character represented by ACHAR(10), etc.
> and then doesn't the length of "\\" have to be 2?
program a
character(len=10) s1, s2
s1 = '\\'
s2 = s1
print '(2I2)', len_trim(s1), len_trim(s2)
end program
troutmask:kargl[210] gfc -o z a.f90
troutmask:kargl[211] ./z
1 1
troutmask:kargl[216] gfc -o z -fno-backslash a.f90
troutmask:kargl[217] ./z
2 2
program a
character(len=10) s1, s2
s1 = '\\'
write(s2,'(A)') s1
print '(2I2)', len_trim(s1), len_trim(s2)
if (s1 /= s2) then
print *, 'Oh, no!'
end if
end program
troutmask:kargl[225] gfc -o z a.f90
troutmask:kargl[226] ./z
1 1
troutmask:kargl[227] gfc -o z -fno-backslash a.f90
troutmask:kargl[228] ./z
2 2
It's unfortunate that people refuse to read the documentation
provided. There is an option to turnoff this behavior. But,
I've grown tired of the whining about gfortran's behavior.
Now, I can watch the others complain about gfortran's gratuitous
differences with g77 compatibility.
Index: ChangeLog
===================================================================
--- ChangeLog (revision 130443)
+++ ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2007-11-26 Steven G. Kargl <kar...@comcast.net>
+
+ * options.c: Change default behavior of backslash processing.
+ * invoke.texi: Update documentation.
+
2007-11-25 Jerry DeLisle <jvde...@gcc.gnu.org>
PR fortran/33152
Index: invoke.texi
===================================================================
--- invoke.texi (revision 130443)
+++ invoke.texi (working copy)
@@ -121,7 +121,7 @@ by type. Explanations are in the follow
-ffixed-line-length-@var{n} -ffixed-line-length-none @gol
-ffree-line-length-@var{n} -ffree-line-length-none @gol
-fdefault-double-8 -fdefault-integer-8 -fdefault-real-8 @gol
--fcray-pointer -fopenmp -fno-range-check -fno-backslash -fmodule-private}
+-fcray-pointer -fopenmp -fno-range-check -fbackslash -fmodule-private}
@item Error and Warning Options
@xref{Error and Warning Options,,Options to request or suppress errors
@@ -233,12 +233,12 @@ Do nothing if this is already the defaul
@cindex character set
Allow @samp{$} as a valid character in a symbol name.
-@item -fno-backslash
-@opindex @code{fno-backslash}
+@item -fbackslash
+@opindex @code{backslash}
@cindex backslash
@cindex escape characters
-Change the interpretation of backslashes in string literals from
-``C-style'' escape characters to a single backslash character.
+Change the interpretation of backslashes in string literals
+from a single backslash character to ``C-style'' escape characters.
@item -fmodule-private
@opindex @code{fmodule-private}
Index: options.c
===================================================================
--- options.c (revision 130443)
+++ options.c (working copy)
@@ -95,7 +95,7 @@ gfc_init_options (unsigned int argc ATTR
gfc_option.flag_repack_arrays = 0;
gfc_option.flag_preprocessed = 0;
gfc_option.flag_automatic = 1;
- gfc_option.flag_backslash = 1;
+ gfc_option.flag_backslash = 0;
gfc_option.flag_module_private = 0;
gfc_option.flag_backtrace = 0;
gfc_option.flag_allow_leading_underscore = 0;
Greg Lindahl
Dick Hendrickson <dick.hen...@att.net> wrote:
> I think most compilers that
> treat a \ as an escape treat "\\" as if it were "\". But, isn't that
> non-conforming?
I bet that every compiler that treats \ as an escape has a
command-line option to turn that behavior off.
And the standard says nothing about command line options.
-- greg
Janne Blomqvist
> ka...@troutmask.apl.washington.edu (Steven G. Kargl) wrote:
>
>> According to the above sentence, gfortran is a conforming Fortran 95
>> compiler because, well surprise, backslash is not a member of the
>> Fortran character set.
>
> I won't debate that point. The point I will debate is that Unix
> is the "mother" operating system whose quirks should be the
> default everywhere. There is no reason to take an arbitrary
> printing character and turn it by default into an escape, other
> than mimicking C and Unix.
>
> Of course Unix and its love children have contributed
> considerably to computing. I just don't think everything in
> computing should be bound to Unix ways of doing things.
There are two issues here.
First, gfortran didn't simply appear out of the vacuum as "just" a
free software Fortran 95 compiler. It also fulfills the role of g77
replacement (which in turn was designed to replace the Unix f77). So,
in order to provide g77/f77 compatibility, it does feature some
"Unixisms". Now, I personally think that changing the default
behaviour towards standard conformance, if necessary by breaking
backwards compatibility, is a good thing. But certainly there are
others who feel differently, and they will soon start to complain how
gfortran 4.3 breaks their old working programs that happened to rely
on C-style escape handling (as Steve already hinted at in another
message). This change in behaviour is(/will be?) of course documented,
but as usual, few people bother to read the release notes.
Secondly, to the best of my knowledge all current gfortran maintainers
are primarily Linux/x86(-64) users. Until that changes, other
operating systems and hardware architectures will have to contend with
second-tier status. Now this doesn't of course mean that gfortran goes
out of its way to make life difficult for people on other targets, but
it does mean that new features and bugfixes are primarily developed on
and tested on Linux/x86(-64).
--
Janne Blomqvist
Dan Nagle
Janne Blomqvist wrote:
> First, gfortran didn't simply appear out of the vacuum as "just" a
> free software Fortran 95 compiler. It also fulfills the role of g77
> replacement (which in turn was designed to replace the Unix f77). So,
> in order to provide g77/f77 compatibility, it does feature some
> "Unixisms". Now, I personally think that changing the default
> behaviour towards standard conformance, if necessary by breaking
> backwards compatibility, is a good thing. But certainly there are
> others who feel differently, and they will soon start to complain how
> gfortran 4.3 breaks their old working programs that happened to rely
> on C-style escape handling (as Steve already hinted at in another
> message). This change in behaviour is(/will be?) of course documented,
> but as usual, few people bother to read the release notes.
I'd like to thank the gfortran developers for changing the default
in response to being criticized in this newsgroup. It takes some
courage to respond to public criticism by changing.
I think the change is a Good Thing, Dick has outlined the proof
of the Theorem that backslash escapes violate even the f95 standard.
(I know there's a counterargument, but I don't like it.) And f03
is completely unambiguous here.
But backwards compatibility is also important, and some will use
the inconvenience of reading release notes as a good excuse
for complaint.
So, Thanks, developers! Thanks for past efforts and the risk
of future complaints.
Michael Prager
> I'd like to thank the gfortran developers for changing the default
> in response to being criticized in this newsgroup. It takes some
> courage to respond to public criticism by changing.
>
> I think the change is a Good Thing, Dick has outlined the proof
> of the Theorem that backslash escapes violate even the f95 standard.
> (I know there's a counterargument, but I don't like it.) And f03
> is completely unambiguous here.
>
> But backwards compatibility is also important, and some will use
> the inconvenience of reading release notes as a good excuse
> for complaint.
>
> So, Thanks, developers! Thanks for past efforts and the risk
> of future complaints.
Let me second Dan! My admiration and appreciation for what has
been accomplished were not obvious in my previous responses. I
do admire and appreciate the hard work that has gone into g77
and gfortran. They have IMO truly helped to keep Fortran a
viable option in many circles.
THANK YOU!
Wade Ward
"Craig Dedo" <cd...@wi.rr.com> wrote in message
news:474adb8d$0$8593$4c36...@roadrunner.com...
> "Wade Ward" <wa...@zaxfuuq.net> wrote in message
> news:1196059...@sp12lax.superfeed.net...
>>
> I believe that your reasoning is faulty on a number of points.
>
> 1. In my experience, doing C language programming professionally for
> over 10 years in commercial environments with real profit-and-loss
> responsibility, the software developers take the relevant language
> standards very seriously. This includes the ISO C and C++ standards. If
> the compiler does not support a particular feature that is in a standard,
> the expectation is that the developer of the compiler is actively working
> to develop that feature for a future version.
That's good to hear.
> Of course, I am well aware that some C and C++ developers have the
> attitude that whatever Emperor Bill decrees is the standard. I can't do
> anything about that except to point out to such people that the ISO is the
> world's official standards body.
> 2. I would write such a function for Fortran programmers, not C
> programmers. The purpose would be to provide a way to allow the
> processing of C language escape sequences while still preserving the
> integrity of the semantic interpretation of Fortran character expressions.
>
> C and C++ language bigots do not use Fortran, except under duress.
> Professional software developers respect the standards and conventions of
> the languages, operating systems, and other tools that they work with.
> Respect for such standards and conventions is part of being a
> professional. Even if a professional software developer has a strong
> preference for C or C++, he or she will respect the standards and
> conventions of Fortran when programming in Fortran.
You question my reasoning. In the above 3 paragraphs I question your facts.
While it is true that the meteoric success and influence of MS drove C++
throughout the eighties, I don't think that Bill's opinion 2007 counts
anymore than mine. First of all, he's retired, and I just can't imagine him
thinking about international comp sci standards. That would be like George
Bush ruminating about the Constitution in the year 2012. Clearly, they
regard these respective documents as toilet paper.
I have no idea what goes on in the c++ world. These people are acutely
aware of their proximity to MS, and I believe they have erected a
sufficiently high wall to have their standrad reflect what is good for their
syntax as opposed to the usual vendor. If I actually laid eyes on their
standard, I could comment further.
With C and MS, my point is that C doesn't talk to MS, not the other way
around. Mention MS in clc and don your asbestos suit....
>
> 3. If I developed such a function, I would need an objective,
> impartial reference framework. The current ISO standard is the best such
> reference.
>
> 4. Technically speaking, any compiler deviations from the provisions
> of the C99 standard are non-standard. They cannot be standard-conforming
> extensions. This is because the C99 standard requires the compiler to
> generate an exception condition if it encounters any escape sequence that
> is not defined in the C99 standard. I pointed this out in an earlier
> message in this thread. There is no flexibility regarding additional
> escape sequences beyond those defined in the C99 standard.
I didn't read this earlier, but now I see your point. Like anything with a
history in C, there's what the current standard says and then an
encyclopedia of past practice. For my own self, what I thought I didn't
know about backslash whatever was in point of fact an underdeveloped
distinction between source and execution sets.
[re-ordered for thematic reasons]
> BTW, if you want a real entertainment, #include all of the header files
> defined in the C99 standard and use some of those features in the "Hello,
> World!" program and try to compile it with MS VC++. Almost certainly, it
> will fail, due to the use of unsupported features. Let's see, C99 has
> been out for nearly 8 years now. Why is that?
Richard Heathfield recently posted a link for the five vendors whose
product had tested as fully-compliant for C-99. I remember thinking that
they would be the usual suspects, inculding Sun and Dinkumware, but
excluding MS. Would anyone expect MS to have a reasonable C99 product?
Well I would, having given myself to the dark empire at a young age, but I
am, like I say, usually in the minority. Most folks including the C vendor
I use, Bloodshed, have enough C compliance to do interoperation where I
think it matters, places like complex.h and boolean types. I'm still
puzzled how the difference between C89 and C99 could show up in printf, but
it does. (Could have something to do with escape sequences, so I guess I'm
on topic.) C's printf function however is variadic, not a candidate for
interop and therefore more boring C in c.l.f.
--
wade ward
wa...@zaxfuuq.net
435 -838-7760
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
FX Coudert
> andhttp://quatramaran.ens.fr/~coudert/gfortran/win64.zip9/21/07
> so I'm up to date as far as Windows is concerned.
You had the latest binaries, but due to lack of resources, this
unfortunately isn't equivalent to having the latest compiler :(
I've just updated both the Win32 and Win64 gfortran binaries (and
added a link to our download page, http://gcc.gnu.org/wiki/GFortranBinaries).
PS: Once again, since I don't have access to a Win64 box, I'm not even
sure the executables it creates will run fine (thought they *seem*
fine). Please let me know (by mail: fxcoudert at gmail dot com) if
there is any difficulty.
--
FX
James Van Buskirk
news:d29c41b5-6e34-486d...@i12g2000prf.googlegroups.com...
> I've just updated both the Win32 and Win64 gfortran binaries (and
> added a link to our download page,
> http://gcc.gnu.org/wiki/GFortranBinaries).
> PS: Once again, since I don't have access to a Win64 box, I'm not even
> sure the executables it creates will run fine (thought they *seem*
> fine). Please let me know (by mail: fxcoudert at gmail dot com) if
> there is any difficulty.
I've looked at the Win64 build enough to be able to say that the
single precision intrinsic problem seems to have been solved and
I haven't seen any regressions, either. Thank you for providing this
service!
--
write(*,*) transfer([3.9435632276541913d180,6.013470016999177d-154], &
['x']);end
step...@gmail.com
It looks like current binaries are broken.
I am trying to compile simple "Hello world" f90 program with
2007-11-30 dated version
of gfortran windows Mingw style binaries:
program f90_proj_simple
print *, 'Hello World'
read *
end program f90_proj_simple
but it outputs following error list:
>gfortran f90_proj_simple.f90
.................................................\python
\f2py_exmaple>gfortran f90_proj_simple.f90
c:/gfortran/bin/../lib/gcc/i386-pc-mingw32/4.3.0/../../../
libgfortran.a(write.o): In function `
output_float':
../../../trunk/libgfortran/io/write_float.def:446: undefined reference
to `__mingw_snprintf'
c:/gfortran/bin/../lib/gcc/i386-pc-mingw32/4.3.0/../../../
libgfortran.a(write.o): In function `
write_float':
../../../trunk/libgfortran/io/write_float.def:792: undefined reference
to `__mingw_snprintf'
../../../trunk/libgfortran/io/write_float.def:801: undefined reference
to `__mingw_snprintf'
../../../trunk/libgfortran/io/write_float.def:796: undefined reference
to `__mingw_snprintf'
c:/gfortran/bin/../lib/gcc/i386-pc-mingw32/4.3.0/../../../
libgfortran.a(open.o): In function `*
__gfortrani_new_unit':
../../../trunk/libgfortran/io/open.c:346: undefined reference to
`__mingw_snprintf'
collect2: ld returned 1 exit status
FX
> to `__mingw_snprintf'
Do you have g95 installed on that same machine? If yes, then that's where
the problem comes from: g95 installs an old version of the mingw runtime
libraries, and (ab)uses a GCC environment variable that forces linking to
it, even though we provide a newer version with gfortran.
The problem was reported to g95 maintainer and window packager (see
http://groups.google.fr/group/gg95/browse_thread/thread/597be895652ad052)
but I'm not sure if one of the fixes I proposed was incorporated. For
you, the two solutions are:
a. install a newer g95 version, maybe it's fixed
b. unset the environment variable LIBRARY_PATH
--
FX
Doug
One of g95 for Windows packages, g95-MinGW-41.exe, uses a new
environment variable, G95_LIBRARY_PATH, in place of LIBRARY_PATH.
This is the Windows package called "gcc 4.1, experimental" on the download
page at http://ftp.g95.org.
Currently, LIBRARY_PATH is still used in the g95-MinGW.exe package built
with gcc 4.0.3. To avoid problems when both g95 and gfortran are present,
install g95-MinGW-41.exe and unset LIBRARY_PATH as FX suggested (see
http://groups.google.com/group/gg95/browse_thread/thread/55687eeadb758c1).
Doug Cox
step...@gmail.com
I really have g95 fortran installed. I unsetted LIBRARY_PATH
variable, and gfortran now works well. I donwloaded g95-MinGW-41.exe
and installed it over C:\Python24\Enthought\MingW, and it also seems
to
work well. Inspite the fact that the gcc in above mingw directory was
3.5.4,
the F2Py works well for both compilers.
Thanks.
Step
On 8 Dec, 17:45, Doug <t...@sentex.net> wrote:
> On December 8, 2007 10:10 am, FX <coud...@alussinan.org> wrote:
>
> >> ../../../trunk/libgfortran/io/write_float.def:446: undefined reference
> >> to `__mingw_snprintf'
>
> > Do you have g95 installed on that same machine? If yes, then that's where
> > the problem comes from: g95 installs an old version of the mingw runtime
> > libraries, and (ab)uses a GCC environment variable that forces linking to
> > it, even though we provide a newer version with gfortran.
>
> > The problem was reported to g95 maintainer and window packager (see
> >http://groups.google.fr/group/gg95/browse_thread/thread/597be895652ad052)
> > but I'm not sure if one of the fixes I proposed was incorporated. For
> > you, the two solutions are:
> > a. install a newer g95 version, maybe it's fixed
> > b. unset the environment variable LIBRARY_PATH
>
> One of g95 for Windows packages, g95-MinGW-41.exe, uses a new
> environment variable, G95_LIBRARY_PATH, in place of LIBRARY_PATH.
>
> This is the Windows package called "gcc 4.1, experimental" on the download
> page athttp://ftp.g95.org.