Error while compiling using CHARACTER*(*) attribute in a NAMELIST
neha
Can anyone help me in finding the solution for the following problem:
I am compiling the following piece of fortran code using f90 compiler
on Solaris10,
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------
SUBROUTINE ENV_DENSITY (LDOCALC, IRHOTOOL, IMUDADD,
& LRMFCORR, RHOB, BHD, CALIIN,
& BS, WMUD, RHOBC, FILL, ISTAT, ERRMSG)
IMPLICIT NONE
LOGICAL LDOCALC ! Do calculations
INTEGER IRHOTOOL ! Density tool type
INTEGER IMUDADD ! Mud additives
LOGICAL LRMFCORR ! Remove field corrections
REAL RHOB ! Bulk density
REAL BHD ! Borehole diameter
REAL CALIIN ! Input caliper
REAL BS
! Bitsize
REAL RHOBC ! Corrected bulk density
REAL WMUD ! Mud weight
REAL FILL ! Absent value
INTEGER ISTAT ! Error status
INTEGER ICD
CHARACTER *(*) ERRMSG ! Error message
INTEGER RHOBTOOL
EXTERNAL RHOBTOOL
REAL SDLBHC
EXTERNAL SDLBHC
REAL HSDLBHC
EXTERNAL HSDLBHC
REAL SLDBHC
EXTERNAL SLDBHC
c Local variables
REAL FCORR
REAL NEWCORR
REAL RHOBNULL ! Density with field correction removed
#ifdef DBGNML
NAMELIST /DBG/ LDOCALC, IRHOTOOL, IMUDADD,
& LRMFCORR, RHOB, BHD, CALIIN,
& BS, WMUD, RHOBC, IDBG, FILL, ISTAT, ERRMSG
#endif
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
While compiling, we are getting the following error:
/opt/SUNWspro/bin/f90 -c -u -DSunOS -Dsunsv -Dunix -DBIGENDIAN -c -g
-DDBGNML=1 -o
/export/views/rdx1007/nj_ncsol/vobs/pci/src/bin/EnvCorr/obj/SunOS/env_density.o
-I. -I/export/views/rdx1007/nj_ncsol/vobs/pci/src/bin/EnvCorr
-I/export/views/rdx1007/nj_ncsol/vobs/pci/src/bin/EnvCorr/src
-I/export/views/rdx1007/nj_ncsol/vobs/pci/src/include/mbsys
-I/export/views/rdx1007/nj_ncsol/vobs/pci/src/include/mbsys
-I/export/views/rdx1007/nj_ncsol/vobs/devkit/LicAppMgr/SunOS/include
/export/views/rdx1007/nj_ncsol/vobs/pci/src/bin/EnvCorr/env_density.F
& BS, WMUD, RHOBC, IDBG, FILL, ISTAT, ERRMSG
^
"/export/views/rdx1007/nj_ncsol/vobs/pci/src/bin/EnvCorr/env_density.F",
Line = 41, Column = 48: ERROR: "ERRMSG" has the CHARACTER*(*)
attribute, therefore it must not be declared as a
namelist-group-object.
f90comp: 133 SOURCE LINES
f90comp: 1 ERRORS, 0 WARNINGS, 0 OTHER MESSAGES, 0 ANSI
gmake: ***
[/export/views/rdx1007/nj_ncsol/vobs/pci/src/bin/EnvCorr/obj/SunOS/env_density.o]
Error 1
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
Also if we compile the code without using NAMELIST, the code is getting
compiled.So is there any restriction about using CHARACTER*(*) with
NAMELIST..??
Thanks in advance
neha
Arjen Markus
I never use NAMELIST, but I can imagine the problem:
CHARACTER*(*) means the string can have _any_ length. This makes
it impossible (?) for the compiler to generate code that will take care
of
the input and output format associated with the namelist. At least that
is my guess (it may be a limitation of the particular compiler).
Regards,
Arjen
dpb
...
> CHARACTER *(*) ERRMSG ! Error message
>
> NAMELIST /DBG/ LDOCALC, IRHOTOOL, IMUDADD,
> & LRMFCORR, RHOB, BHD, CALIIN,
> & BS, WMUD, RHOBC, IDBG, FILL, ISTAT, ERRMSG
> Line = 41, Column = 48: ERROR: "ERRMSG" has the CHARACTER*(*)
> attribute, therefore it must not be declared as a namelist-group-object.
>
>
> Also if we compile the code without using NAMELIST, the code is getting
> compiled.So is there any restriction about using CHARACTER*(*) with
> NAMELIST..??
>
Arjen has the underlying reason correct and, yes, there is there is a
restriction and the compiler error message was pretty explicit as to
what particular restriction was attempted...
>From CVF documentation (not the Standard's exact wording, but the
restrictions are Standard)....
"The following variables cannot be specified in a namelist group:
An array dummy argument with nonconstant bounds
A variable with assumed character length
An allocatable array
An automatic object
A pointer
A variable of a type that has a pointer as an ultimate component
A subobject of any of the above objects ... "
Michael Metcalf
"neha" <tcs....@gmail.com> wrote in message
news:1168854889.4...@a75g2000cwd.googlegroups.com...
> CHARACTER *(*) ERRMSG ! Error message
The code is illegal. A variable in the namelist list must not be one with a
non-constant character length (see "Fortran 95/2003 Explained", Section
7.15).
Regards,
Mike Metcalf
glen herrmannsfeldt
I had first thought it would have the same problem for dummy
arrays with variable dimensions, but it seems that those are
also excluded.
As OS/360 Fortran was the first I used with NAMELIST, I
decided to check what restrictions it has. It seems that
for OS/360, all dummy variables and arrays are not allowed.
In that case, the addresses and lengths are known at compile
time, and can be compiled into a table of names, addresses,
and lengths.
It would seem not so hard to do in newer systems, and
one might hope for non-constant strings and arrays as
an extension.
-- glen
neha
confused about one thing that this piece of code used to work with SUN
f77 compiler and with google's help i was able to find that:
"Arrays and character strings with variable lengths are not allowed on
Fortran 95 NAMELIST statements."
Also I m using compiler f90 and not f95...So will the information that
"Arrays and character strings with variable lengths are not allowed on
Fortran 95 NAMELIST statements." be valid for Sun f90 compiler
also...??
Thanks in advance.
Neha
Michael Metcalf
> Thank u all for ur responses...I m totally new to fortran....but i am
> confused about one thing that this piece of code used to work with SUN
> f77 compiler and with google's help i was able to find that:
>
NAMELIST was a non-standard extension in FORTRAN 77.
> "Arrays and character strings with variable lengths are not allowed on
> Fortran 95 NAMELIST statements."
>
> Also I m using compiler f90 and not f95...So will the information that
> "Arrays and character strings with variable lengths are not allowed on
> Fortran 95 NAMELIST statements." be valid for Sun f90 compiler
> also...??
>
The terms f90 and f95 are often used interchangeably. For your purposes they
are almost identical. To all intents and purposes, all modern compilers are
f95 conforming.
Regards,
Mike Metcalf
Richard Maine
> Thank u all for ur responses...I m totally new to fortran....but i am
> confused about one thing that this piece of code used to work with SUN
> f77 compiler and with google's help i was able to find that:
>
> "Arrays and character strings with variable lengths are not allowed on
> Fortran 95 NAMELIST statements."
>
> Also I m using compiler f90 and not f95...So will the information that
> "Arrays and character strings with variable lengths are not allowed on
> Fortran 95 NAMELIST statements." be valid for Sun f90 compiler
> also...??
As Mike says, Namelist was a nonstandard extension to f77. Just because
something is not part of the standard language, that doesn't mean it
won't necessarily work on some compilers. The above-cited statement
about what is allowed in Fortran 95 is about the standardized Fortran
language - not about a particular compiler.
Compilers are not required to enforce all the prohibitions of the
standard. In some cases, a compiler has an intentional extension. In
other cases, it just neglects to catch a user error (and the resulting
code might or might not work as intended).
So in some sense, it doesn't make sense to ask whether the claim that
".. are not allowed on Fortran 95 Namelist statements" is true for a
compiler, since it isn't a question about a compiler. A literal answer
would have to be that, yes, the claim is valid for the Sun compiler,
which is to say that the Namelist statements in question are not valid
Fortran 95 statements on that compiler or any other. Such Namelist
statements might be accepted by the compiler, but that isn't the same
question. One might say that they are not Fortran 95 statements, but
that the Sun F95 compiler accepts them anyway.
I don't know whether the Sun f95 compiler accepts them or not, by the
way. I'm just explaining what it would mean if it does.
Note that to the extent that you leave nonstandard code in the program,
you can expect to have continuing portability problems. Unless Sun
documents support of this feature as a supported extension, that might
concievably even include porting the code to a future release of the
same compiler. I somewhat doubt that would happen in this case, but I
have seen other cases where people took advantage of what they viewed as
a feature of a compiler, which was then fixed in a future release.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
robert....@sun.com
neha wrote:
> Thank u all for ur responses...I m totally new to fortran....but i am
> confused about one thing that this piece of code used to work with SUN
> f77 compiler and with google's help i was able to find that:
>
> "Arrays and character strings with variable lengths are not allowed on
> Fortran 95 NAMELIST statements."
>
> Also I m using compiler f90 and not f95...So will the information that
> "Arrays and character strings with variable lengths are not allowed on
> Fortran 95 NAMELIST statements." be valid for Sun f90 compiler
> also...??
Sun f77 did allow variables of type CHARACTER*(*) in namelists.
Sun f90/f95 does not. It would not be particularly hard to support
the feature, but until now we have not received any requests for it.
Bob Corbett
neha
used for backward compatability of f90 compiler with f77.
I tried using "-f77" option with f90 compiler but that is not solving
my problem...??
Thanks in advance
Neha
Richard Maine
(in article <1169025892.3...@l53g2000cwa.googlegroups.com>):
> Thanks a lot Bob for your response, but is there any flag that can be
> used for backward compatability of f90 compiler with f77.
> I tried using "-f77" option with f90 compiler but that is not solving
> my problem...??
> robert....@sun.com wrote:
>> Sun f77 did allow variables of type CHARACTER*(*) in namelists.
>> Sun f90/f95 does not. It would not be particularly hard to support
>> the feature, but until now we have not received any requests for it.
I think you aren't understanding Robert's reply. Either that or you are
phrasing a feature request as a rhetorical question. Robert said that Sun
f90/f95 does not allow it, and that it would not be particularly hard to
support it. That means the answer to your literal question is "no". If there
were an existing compiler switch, then that would be supporting it now, as
opposed to being "not particularly hard" to support.
I'll throw in my usual knee-jerk comment that sticking to the standard avoids
a lot of problems like this, even though it can add awkwardness in coding on
occasion. Avoiding problems like this is what the standard is for.
I'll also note that I don't see any big reason why the standard couldn't be
extended to allow this in the future. When Namelist was added to the standard
(in f90), it was done in a pretty conservative and minimalist fashion in
several regards. In my personal judgement, this particular restriction was
probably overkill in that I wouldn't expect it to be hard to implement in
most compilers. (Not that I'm a compiler writer, so I'm not really in a
position to know, but that would be my guess). I think that the reason the
standard hasn't been enhanced in this way is much the same as the reason
Robert gave that the Sun compiler hasn't been enhanced - nobody asked (or at
least not many people asked, or they didn't ask very hard).
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
robin
news:1168869064.1...@51g2000cwl.googlegroups.com...
>
> I never use NAMELIST, but I can imagine the problem:
> CHARACTER*(*) means the string can have _any_ length. This makes
> it impossible (?) for the compiler to generate code that will take care
> of the input and output format associated with the namelist.
It won't. At run time, ERRMSG will have a length,
and the output string is perfectly defined for output.
Even if it were input, the same considerations apply -
namely, ERRMSG will have a definite length,
and so does the input string, therefore an assignment is
perfectly feasible.
Others have commented on the legality of the construct.