Home > Archive > Fortran > October 2006 > Specific names for intrinsic functions and optional arguments
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Specific names for intrinsic functions and optional arguments
|
|
|
| Hi all,
I'm having trouble locating the relevant part of the Standard... my
question is the following: some intrinsic functions have optional
arguments, like INDEX (STRING, SUBSTRING [, BACK, KIND]); these arguments
are allowed to have any kind. Now, when passed as actual arguments to a
subroutine, how are these optional arguments handled? I don't think the
compiler has any way to recognize their kind, so I guess using optional
arguments must be forbidden in that case..
In short, is the following code legal, and why/why not?
subroutine foo(a)
integer :: a
print *, a("foobarfoobar", "bar", .true.)
end subroutine
intrinsic index
print *, index ("foobarfoobar", "bar", .true.)
call foo(index)
end
And if it's legal, is it still legal when .true. is replaced by
..true._anykind?
Thanks,
--
FX
| |
|
|
FX wrote:
> Hi all,
>
> I'm having trouble locating the relevant part of the Standard... my
> question is the following: some intrinsic functions have optional
> arguments, like INDEX (STRING, SUBSTRING [, BACK, KIND]); these arguments
> are allowed to have any kind. ...
No, I believe that is wrong. The optional arguments are default
logical and default integer, respectively. Only the result is of kind
as specified by the optional KIND argument (assuming, of course, the
processor/compiler support the requested KIND).
| |
|
| > No, I believe that is wrong. The optional arguments are default
> logical and default integer, respectively. Only the result is of kind
> as specified by the optional KIND argument (assuming, of course, the
> processor/compiler support the requested KIND).
I don't see where this would come from... quoting the F2003 draft:
13.7.52 INDEX (STRING, SUBSTRING [, BACK, KIND])
Description. Returns the starting position of a substring within a
string.
Class. Elemental function.
Arguments.
-- STRING shall be of type character.
-- SUBSTRING shall be of type character with the same kind type parameter as
STRING.
-- BACK (optional) shall be of type logical.
-- KIND (optional) shall be a scalar integer initialization expression.
--
FX
| |
| Richard Maine 2006-10-01, 7:03 pm |
| dpb <dpbozarth@swko.net> wrote:
> FX wrote:
>
> No, I believe that is wrong. The optional arguments are default
> logical and default integer, respectively.
No they are not. If there were such a requirement, the standard would
actually say so; the word "default" would be in there. It isn't. The OP
is correct that they are allowed to be of any kind.
The answer to the OP's question is that for the most part you can't pass
such functions as actual arguments at all, so the question is mostly
moot. There is only a very small list of intrinsic procedures that may
be passed as actual arguments. That list is mostly historical. If you
study it, you will notice that it is predominantly (perhaps even
entirely) intrinsics from f66. F77 introduced genericity to intrinsics.
Passing generics as actual arguments is not allowed.
I do think I recall noting that f2003 added a KIND argument to one or
two of the intrinsics that have specifics that can be passed as actual
arguments. What I don't recall is whether the resulting integration
problem got noticed in time to fix it in the standard or not. (One of my
long-standing and continuing pet peeves is that integration work always
gets shortchanged in favor of adding new features. That's happening with
f2008 now. I find the whole idea of putting interp work for existing
features on hold in order to work on adding new features to be, well...
words escape me... at least suitably polite words do.)
In any case, whether the fix actually made it into the standard or not,
I don't recall, but even if it didn't make it in, I am essentially
certain what the answer would "have" to be. Insomuch as the main purpose
(and perhaps the only one) of still allowing those specific intrinsics
as actual arguments is compatibility with old codes, I conclude that it
would make no sense at all to change things in a way that would break
all old codes that used them that way. Therefore, the answer "has" to be
that the specific that is passed in such situations is one without the
optional arguments at all. One could write the standard-speak for that
in several ways, but that "has" to be the essense of the answer.
Of course, no matter how much I am convinced that this "has" to be the
answer, that doesn't make it official. But I'm pretty confident of my
call on it.
And as I said, it is only one or two intrinsics. INDEX is not one of
them.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| Walter Spector 2006-10-01, 7:03 pm |
| Richard Maine wrote:
> ...
> And as I said, it is only one or two intrinsics. INDEX is not one of
> them.
In both §13.13 of F95, and §13.6 of F2003, INDEX appears to be both
generic and allowed as a specific name for passing to a subprogram.
(No 'bullet' indicating that it can not be used for this purpose.)
The interesting difference between F95 and F2003 appears to be that in
F95, INDEX's 'specific name' seems to include a type 'signature' of
INDEX (STRING, SUBSTRING) - *without* the optional 'back' argument.
In F2003, there does not seem to be this distinction. This would seem
to infer that the callee could have an INTERFACE block with optional
args specified, and then use the optional args as needed.
With a only a few minutes of fiddling with this, I could get neither
g95, nor gfortran (older version) to work right. Will try ifort and
IRIX f90 later.
Fun case!
Walt
| |
| Richard Maine 2006-10-02, 4:04 am |
| Walter Spector <w6ws_xthisoutx@earthlink.net> wrote:
> Richard Maine wrote:
>
> In both §13.13 of F95, and §13.6 of F2003, INDEX appears to be both
> generic and allowed as a specific name for passing to a subprogram.
> (No 'bullet' indicating that it can not be used for this purpose.)
Ah. I had the darned bullets backwards, thinking they were the ones that
could be used. You are right on that.
> The interesting difference between F95 and F2003 appears to be that in
> F95, INDEX's 'specific name' seems to include a type 'signature' of
> INDEX (STRING, SUBSTRING) - *without* the optional 'back' argument.
> In F2003, there does not seem to be this distinction. This would seem
> to infer that the callee could have an INTERFACE block with optional
> args specified, and then use the optional args as needed.
Hmm. I'd question whether that would hold up in an interp. It would seem
to be an incompatibility between f90/f95 and f2003, which I doubt was
intended (and which isn't listed as an incompatibility). Because that
would seem to make any f90 code that passed index as an actual argument
illegal. Maybe index was one of the cases where I was recalling this
issue. I remembert seeing an issue like that, but didn't recall the
details of which intrinsics it was.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| glen herrmannsfeldt 2006-10-02, 4:04 am |
| Richard Maine wrote:
(snip)
> The answer to the OP's question is that for the most part you can't pass
> such functions as actual arguments at all, so the question is mostly
> moot. There is only a very small list of intrinsic procedures that may
> be passed as actual arguments. That list is mostly historical. If you
> study it, you will notice that it is predominantly (perhaps even
> entirely) intrinsics from f66. F77 introduced genericity to intrinsics.
> Passing generics as actual arguments is not allowed.
As far as I know, the most common reason for passing a function as
an actual argument in Fortran is for numerical integration routines.
While usually this is a user written function there might be some times
to integrate an intrinsic function. INDEX is not likely to be used
for numerical integration. That doesn't mean there is no use for it
as an actual argument, though.
-- glen
| |
|
| > In both §13.13 of F95, and §13.6 of F2003, INDEX appears to be both
> generic and allowed as a specific name for passing to a subprogram.
> (No 'bullet' indicating that it can not be used for this purpose.)
>
> The interesting difference between F95 and F2003 appears to be that in
> F95, INDEX's 'specific name' seems to include a type 'signature' of
> INDEX (STRING, SUBSTRING) - *without* the optional 'back' argument.
> In F2003, there does not seem to be this distinction. This would seem
> to infer that the callee could have an INTERFACE block with optional
> args specified, and then use the optional args as needed.
>
> With a only a few minutes of fiddling with this, I could get neither
> g95, nor gfortran (older version) to work right. Will try ifort and
> IRIX f90 later.
I asked this question because, while debugging and polishing the way
gfortran treats intrinsics use as actual arguments, I encountered this
problem and could not figure out how it is supposed to work.
--
FX
| |
|
| >> The interesting difference between F95 and F2003 appears to be that in
>
> Hmm. I'd question whether that would hold up in an interp. It would
> seem to be an incompatibility between f90/f95 and f2003, which I doubt
> was intended (and which isn't listed as an incompatibility). Because
> that would seem to make any f90 code that passed index as an actual
> argument illegal. Maybe index was one of the cases where I was
> recalling this issue. I remembert seeing an issue like that, but didn't
> recall the details of which intrinsics it was.
From what I found while polishing gfortran support for these, there are
only 5_intrinsics that have this kind of problem:
-- INDEX: allowed as actual arg in F95 and F2003, in F95 its specific
version isn't allowed a BACK argument; in F2003 it has a second optional
arg, KIND, and nothing is said about these optional args when called as
specific.
-- CHAR: not allowed in F95, allowed in F2003, and nothing is said in
F2003 about its optional KIND argument when called as specific.
-- AINT, ANINT and NINT: allowed in both F95 and F2003, in F95 the
specific version isn't allowed to be called with a KIND arg, while in
F2003 nothing is said.
What I'd suggest is for the Standard Committee[1] to use in the next
standard version a list of "specific names for intrinsic functions" that
includes the arguments, like F95 did. It's really clearer.
In the meantime, I think the best thing for consistency is to consider
that the specific versions of INDEX, CHAR, AINT, ANINT and NINT should
not be called with any of the optional arguments of their generic
version. Does that seem OK to everyone? And is there a way to get an
official position about this problem?
[1] or whatever it's called
--
FX
| |
| Walter Spector 2006-10-02, 7:03 pm |
| FX wrote:
>
>
> I asked this question because, while debugging and polishing the way
> gfortran treats intrinsics use as actual arguments, I encountered this
> problem and could not figure out how it is supposed to work.
Well, I've now tried tests with Salford (version 4.60 - which is old),
ifort 9.something, and SGI IRIX f90 (v7.4.4m). Consider the following:
program specifics
implicit none
intrinsic :: index
print *, index ("foobarfoobar", "bar", .true.)
call foo(index)
contains
subroutine foo (a)
interface
integer function a (str1, str2)
character(*), intent(in) :: str1, str2
end function
end interface
print *, a ("foobarfoobar", "bar")
end subroutine
end program
As previously noted, I could not get either g95 nor gfortran to compile
this. However Salford, ifort, and IRIX all do. When run, the program
prints the expected "10" and "4" on all three of the latter. So clearly
both g95 and gfortran have bugs here.
Interestingly, if I specify an "optional" BACK dummy arg in the interface
block, all three compile the code. This, I would think, is an extension
to F95 - since it extends on the stated arg lists in §13.13. Both ifort
and IRIX again print "10" and "4". However Salford prints "10" and "0".
So Salford failed to either diagnose the problem, or support the extension.
I then added an optional KIND arg. At this point the IRIX compiler
diagnosed that "No specific intrinsic exists...". Intel supports the
F2003 KIND arg, and so again compiled silently and produced the
expected results. (Salford again compiled quietly, then produced bad
results.)
Last, I added a bogus arg. Intel then detected an error ("intrinsic
procedure reference contains too many arguments").
I still wonder what F2003 had in mind on this when they removed the
dummy arg lists. It seems broken...
Walt
| |
| Richard Maine 2006-10-02, 7:03 pm |
| FX <coudert@alussinan.org> wrote:
> In the meantime, I think the best thing for consistency is to consider
> that the specific versions of INDEX, CHAR, AINT, ANINT and NINT should
> not be called with any of the optional arguments of their generic
> version. Does that seem OK to everyone?
Um. No. But maybe its just that my disagreement is just with the
terminology used to express it rather than with what you mean. One
doesn't actually call (or otherwise reference) the specific versions
directly at all. I think there might be one obscure case, but I'd have
to work to try to reconstruct it if I can do so at all; if there is such
a case, the optional arguments would not be a problem.
The only issue here is what happens when these intrinsics are passed as
actual arguments. I'd describe it that way - not as a specific versus
generic matter. It does so happen that you can only pass a specific as
an actual argument, and it is otherwise at least difficult to even refer
to the specific. Anyway, I understand it more clearly when one talks
about passing it as an actual argument.
And then the actual reference is to the dummy procedure - not directly
to the intrinsic. So that leads me further afield in following exactly
what you mean here. What I would say is to assume that the actual
procedure passed is one without the optional arguments. This has little
to do with whether the dummy ever gets referenced at all. Once you know
what the actual procedure in question is, all the other rules follow as
usual.
I think we are saying basically the same thing except that you are
skipping ahead to a slightly imprecise statement of the consequence in
the most usual situation, while I'm trying to keep back at a more
precise statement at the point where the problem arises.
Anyway, that seems relatively safe to me because that's basically saying
to use the f77 forms. I have trouble imagining the committee
retroactively ruling that we have an incompatibility with f77 that
nobody thought of before. Particularly since in my view, passing
generics is a feature whose only reason is compatibility.
I'd say that even better advice would be to not pass generics as actual
arguments. How often does that actually come up in real applications. I
have trouble imagining it. I'm not sure I have ever done so in my whole
career. I'm not asking about whether one could invent a case where it
could be used; that's trivial. I'm asking about whether it actually does
come up instead of get imagined as possible to come up.
I see the question as more academic than practical. After all, I've seen
the question come up now at least twice as an academic question. But I
have yet to see a single actual program where it was an issue, and it
has been a decade and a half.
And in the unlikely case that the INDEX function was just right for an
actual argument in some situation, I'd probably wrap it (trivially) in
my own module function to eliminate any question.
> And is there a way to get an official position about this problem?
Of course. I thought you knew about all that. That's basically what
interpretation requests are about. However, do be aware that the
mechanics of the official process make it take a *LONG* time to get an
answer that is actually official. To get an unofficial sense of the
committee is one thing, but an actually official answer tales literally
years - typically plural. Heck, even if a draft answer was prepared
imediately and never had any controversy or other holdup at all, it
could easily take well over a year just to work its way through the
formalities of the bureaucratic process. And no, you can't skip those
formalities; those are what make it official.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| glen herrmannsfeldt 2006-10-02, 7:03 pm |
| Richard Maine <nospam@see.signature> wrote:
(big snip)
> I'd say that even better advice would be to not pass generics as actual
> arguments. How often does that actually come up in real applications. I
> have trouble imagining it. I'm not sure I have ever done so in my whole
> career. I'm not asking about whether one could invent a case where it
> could be used; that's trivial. I'm asking about whether it actually does
> come up instead of get imagined as possible to come up.
As I said before, numeric integration routines might be one of
the more popular used for passing functions as actual arguments.
(Root finders and extrema finders are another popular use.)
I wouldn't expect integration of an intrinsic to come up in a
real problem, but it might be nice when trying out such a routine.
Maybe integrate SQRT from 0 to 1 and see if it gets the right answer.
But it seems that SQRT is one that can be used as an actual argument,
though more likely DSQRT would be used.
It seems that ERF still isn't an intrinsic, though I believe
some have it as an extension. There might be some use for
integrating ERF.
It isn't that hard to write a function that calls SQRT, and that
will be needed for any real problem, anyway.
-- glen
| |
| Richard Maine 2006-10-02, 7:03 pm |
| glen herrmannsfeldt <gah@seniti.ugcs.caltech.edu> wrote:
> Richard Maine <nospam@see.signature> wrote:
>
> (big snip)
>
> As I said before, numeric integration routines might be one of
> the more popular used for passing functions as actual arguments.
> (Root finders and extrema finders are another popular use.)
>
> I wouldn't expect integration of an intrinsic to come up in a
> real problem,
Yes. That's exacly why I mentioned an actual application instead of an
imagined one. You have an imagined one. I've seen plenty of such
hypothesized ones. I have yet to see an actual one. As you say, people
don't use numerical integration routines to integrate sin(x). Sure,
again, I could invent a scenarios where it might make sense to do so...
but I haven't seen that scenario actually happen - ever. Have you?
Anything that includes phrases like "there might be some use for" is
automatically disqualified.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
|
| > I think we are saying basically the same thing except that you are
> skipping ahead to a slightly imprecise statement of the consequence in
> the most usual situation, while I'm trying to keep back at a more
> precise statement at the point where the problem arises.
I do think we are saying the same, but you're actually saying it right
and I'm using both inappropriate terminology and approximative
statements. Doh.
> I'd say that even better advice would be to not pass generics as actual
> arguments.
Well, that might work when you write your own code (and I promise, I
never passed generics as actual arguments in my code, and do not intend
to) but that doesn't work when you're writing a compiler :)
Although I imagine the thing ;-)
$ gfortran a.f90
error: in file a.90, at line 45:
error: The GNU Fortran team and the Surgeon General reminds you that
error: passing intrinsic INDEX as actual argument to function FOO is
error: hazardous for your health and may be seen as a bad coding practice.
error: gfortran will not let you do that. Aborting now.
--
FX
| |
| Richard Maine 2006-10-03, 8:12 am |
| Richard Maine <nospam@see.signature> wrote:
> in my view, passing
> generics is a feature whose only reason is compatibility.
>
> I'd say that even better advice would be to not pass generics as actual
> arguments.
Of course, I meant "intrinsics" instead of generics both places above.
People seemed to respond to what I meant instead of what I said, but
I'll correct myself for the record anyway.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
|
| > I think we are saying basically the same thing except that you are
> skipping ahead to a slightly imprecise statement of the consequence in
> the most usual situation, while I'm trying to keep back at a more
> precise statement at the point where the problem arises.
I do think we are saying the same, but you're actually saying it right
and I'm using both inappropriate terminology and approximative
statements. Doh.
> I'd say that even better advice would be to not pass [intrinsics] as
> actual arguments.
Well, that might work when you write your own code (and I promise, I
never passed intrinsics as actual arguments in my code, and do not intend
to) but that doesn't work when you're writing a compiler :)
Although I imagine the thing ;-)
$ gfortran a.f90
error: in file a.90, at line 45:
error: The GNU Fortran team and the Surgeon General reminds you that
error: passing intrinsic INDEX as actual argument to function FOO is
error: hazardous for your health and may be seen as a bad coding practice.
error: gfortran will not let you do that. Aborting now.
--
FX
| |
| Brooks Moses 2006-10-03, 8:12 am |
| FX wrote:
[Quoting Richard Maine]
>
> Well, that might work when you write your own code (and I promise, I
> never passed generics as actual arguments in my code, and do not intend
> to) but that doesn't work when you're writing a compiler :)
>
> Although I imagine the thing ;-)
>
> $ gfortran a.f90
> error: in file a.90, at line 45:
> error: The GNU Fortran team and the Surgeon General reminds you that
> error: passing intrinsic INDEX as actual argument to function FOO is
> error: hazardous for your health and may be seen as a bad coding practice.
> error: gfortran will not let you do that. Aborting now.
:ADDPATCH fortran:
========================================
===========================
--- gfortran.texi (revision 117359)
+++ gfortran.texi (working copy)
@@ -365,6 +365,13 @@
@item -fsyntax-only
Check the code for syntax errors, but don't do anything beyond that.
+ @item -Wdumb-programming
+ Produces a warning when the user does something that is a bad idea.
+ This includes passing intrinsics as arguments, implicitly saving
+ variables via assignment in procedures, assigning single-precision
+ literals to double-precision variables, and comparing two real
+ numbers for exact equality.
+
@item -pedantic
Issue warnings for uses of extensions to FORTRAN 95.
========================================
===========================
Hey, I just do documentation patches! Someone else can write up the
corresponding code patches. :)
- Brooks
--
The "bmoses-nospam" address is valid; no unmunging needed.
| |
| Gordon Sande 2006-10-03, 8:12 am |
| On 2006-10-03 04:14:04 -0300, Brooks Moses
<bmoses-nospam@cits1.stanford.edu> said:
>
> + @item -Wdumb-programming
> + Produces a warning when the user does something that is a bad idea.
> + This includes passing intrinsics as arguments, implicitly saving
> + variables via assignment in procedures, assigning single-precision
> + literals to double-precision variables, and comparing two real
> + numbers for exact equality.
>
I have serious applications which deal with large whole numbers (think
dollar amounts) that may be beyond the range of integers but well within
the range of the size of double precision mantissas of the usual 32
bit computers. The values can be missing, zero or positive so a convenient
missing flag is minus one. The result is many exact comparisons with
minus one to notice the missing values. When the values can be missing
or negative, zero or positive then the detection of missing is more
trouble.
The point is that not all exact comparisons of reals are "dumb programming".
One might even say that the rote repeating of such often sensible advice
amounts to "dumb thinking". I have had to turn off such helpful warnings
in several compilers. The proposal does not seem to have the ability to
turn off its helpful, but occasionally rather ill advised, commentary.
I know you were trying to be funny as part of an extended joke but it
got repeated one time too many so I thought it about time to point out
its problem.
| |
| Dan Nagle 2006-10-03, 8:12 am |
| Hello,
Gordon Sande wrote:
<snip>
> The point is that not all exact comparisons of reals are "dumb
> programming".
> One might even say that the rote repeating of such often sensible advice
> amounts to "dumb thinking". I have had to turn off such helpful warnings
> in several compilers. The proposal does not seem to have the ability to
> turn off its helpful, but occasionally rather ill advised, commentary.
I disagree. A better scheme is to use, e.g., NaN or Infinity
as the signal value, and a distinct predicate function
to detect it. Someday, your software may be extended to include
amounts that may be negative.
I don't like in-band signaling, it's too easy to produce
non-reusable software. YMMV, I suppose.
<snip>
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
| Gordon Sande 2006-10-03, 8:12 am |
| On 2006-10-03 10:03:44 -0300, Dan Nagle <dannagle@verizon.net> said:
> Hello,
>
> Gordon Sande wrote:
>
> <snip>
>
>
> I disagree. A better scheme is to use, e.g., NaN or Infinity
> as the signal value, and a distinct predicate function
> to detect it. Someday, your software may be extended to include
> amounts that may be negative.
>
> I don't like in-band signaling, it's too easy to produce
> non-reusable software. YMMV, I suppose.
>
> <snip>
What is your method for systems that do not have NaN or Infinity?
Other than wait for them to become available.
As an abstract notion in-band signaling is not ideal. But many things
including current Fortran are not ideal! Claiming that things are not
ideal
The awkwardness of out-of-band signaling are usually so severe that
when in-band signaling can be guaranteed to be safe it rather conveninent.
I know about keeping separate missing flags when all data values might
be present and it a major PITA even if it the way to go. Been there, done
that and have the tee-shirt to prove it. Thanks for the careful snipping
of the original comments on full range of data values. But that is usenet
in all its glory.
| |
| glen herrmannsfeldt 2006-10-03, 7:02 pm |
| Gordon Sande wrote:
(snip on excessive warnings, which I usually agree with, except that
once in a while one actually catches something real.)
> I have serious applications which deal with large whole numbers (think
> dollar amounts) that may be beyond the range of integers but well within
> the range of the size of double precision mantissas of the usual 32
> bit computers. The values can be missing, zero or positive so a convenient
> missing flag is minus one. The result is many exact comparisons with
> minus one to notice the missing values. When the values can be missing
> or negative, zero or positive then the detection of missing is more
> trouble.
The right answer is 64 bit integers, though they are not supported
on all systems. For floating point processors before the IEEE standard,
I don't know if I would always count on that. If you do division,
though, it is much less obvious.
> The point is that not all exact comparisons of reals are "dumb
> programming".
> One might even say that the rote repeating of such often sensible advice
> amounts to "dumb thinking". I have had to turn off such helpful warnings
> in several compilers. The proposal does not seem to have the ability to
> turn off its helpful, but occasionally rather ill advised, commentary.
For non-integer values on processors that sometimes use more precision
than specified, it is fairly easy to have supposedly equal floating
point values turn out not equal. Instead of testing for -1, you
could just test for less than zero.
-- glen
| |
| Richard E Maine 2006-10-03, 7:02 pm |
| Gordon Sande <g.sande@worldnet.att.net> wrote:
> The point is that not all exact comparisons of reals are "dumb programming".
I agree. I've fairly often done it for special "flag" values. Not that I
like to overuse flag values for what aamounts to out-of-band
communication, but it happens on occasion.
I also sometimes use IEEE double to pass data that is purely integer not
because of the 32-bit vs 64-bit issue, but just for simplicity. If you
have an array of dataa, some of which is real and some of which is
integer, it is a *LOT* simpler to deal with if you convert all the
integers to real (I'm talking "honest" conversion here - not equivalence
games).
Every time I've ever seen warnings anout exact floating point
conversions in my code, the warnings have been bogus. Admitedly, that's
not always been so for other people's codes that I've looked at.
But this is relatively rare enough that I doesn't bug me too much. For a
bogus warning that *REALLY* bugs me, the one that comes to mind at the
moment is the warning I get from some compilers for constructs like
character*32 :: name !-- Or use whatever syntax you like here.
... (name gets defined somewhere here)
name = trim(name) // '.suffix'
where the compiler warns me that this might get truncated. I *HATE* that
one. It strikes me as about as useful as warning me for every floatting
point addition that the result might be rounded.
I also get a bazillion warnings in my codes for unused dummy arguments.
They are a "natural" result of having an subroutine interface definition
that allows for more capability than some particular implementations of
the subroutine use. You don't redfine the interface just because a
particular subroutine doesn't need all of it. The extreme (and quite
common in my code) case of this is a stub placeholder routine that does
nothing in my release code, but is designed to be replaceable by the
user. I have enough of those that it is hard to paw through the
resulting bogus warnings to see if there are any real ones. Fortunately,
some compilers provide the ability to turn off that warning without
turning off all warnings.
Oh. And Brooks, I know it was all at least somewhat humorous, but please
don't describe initializers as being "assignments". That seems likely to
encourage the confusion, since the recommend fix for the misunderstading
is to change them into assignments.
--
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
| |
| Gordon Sande 2006-10-03, 7:02 pm |
| On 2006-10-03 13:45:28 -0300, nospam@see.signature (Richard E Maine) said:
> Gordon Sande <g.sande@worldnet.att.net> wrote:
>
>
> I agree. I've fairly often done it for special "flag" values. Not that I
> like to overuse flag values for what aamounts to out-of-band
--in--?
> communication, but it happens on occasion.
It is old telco jargon where tin whistles and such could disable long
distance charges, etc. The special tones were on the same wires (in-channel)
so the whistle could override the system intent. The solution was
out-of-channel signalling so they now have twice as many places that things
can go wrong. ;-) But they cured the tin whistle problem.
> I also sometimes use IEEE double to pass data that is purely integer not
> because of the 32-bit vs 64-bit issue, but just for simplicity. If you
> have an array of dataa, some of which is real and some of which is
> integer, it is a *LOT* simpler to deal with if you convert all the
> integers to real (I'm talking "honest" conversion here - not equivalence
> games).
>
> Every time I've ever seen warnings anout exact floating point
> conversions in my code, the warnings have been bogus. Admitedly, that's
> not always been so for other people's codes that I've looked at.
Which is why the ability to disable warnings selectively is so helpful.
> But this is relatively rare enough that I doesn't bug me too much. For a
> bogus warning that *REALLY* bugs me, the one that comes to mind at the
> moment is the warning I get from some compilers for constructs like
>
> character*32 :: name !-- Or use whatever syntax you like here.
> ... (name gets defined somewhere here)
> name = trim(name) // '.suffix'
I have not hit that one, yet. (Knock on wood or whatever.)
> where the compiler warns me that this might get truncated. I *HATE* that
> one. It strikes me as about as useful as warning me for every floatting
> point addition that the result might be rounded.
>
> I also get a bazillion warnings in my codes for unused dummy arguments.
> They are a "natural" result of having an subroutine interface definition
> that allows for more capability than some particular implementations of
> the subroutine use. You don't redfine the interface just because a
> particular subroutine doesn't need all of it. The extreme (and quite
> common in my code) case of this is a stub placeholder routine that does
> nothing in my release code, but is designed to be replaceable by the
> user. I have enough of those that it is hard to paw through the
> resulting bogus warnings to see if there are any real ones. Fortunately,
> some compilers provide the ability to turn off that warning without
> turning off all warnings.
Ahmen brother! I would really like some way of turning the warning off
by routine. It is so annoying that I would even use a compiler directive.
At the other extreme I keep hoping that some compiler will flag the use
of a common block in which no variables are used. Or a module that has
nothing referenced. I appreciate the unused variables diganostics but
would like the same for the variable grouping constructs.
> Oh. And Brooks, I know it was all at least somewhat humorous, but please
> don't describe initializers as being "assignments". That seems likely to
> encourage the confusion, since the recommend fix for the misunderstading
> is to change them into assignments.
Bogus warnings are worse than no warning because they mask the presence of
real diagnostics.
| |
| Dan Nagle 2006-10-03, 7:02 pm |
| Hello,
Gordon Sande wrote:
<snip>
> At the other extreme I keep hoping that some compiler will flag the use
> of a common block in which no variables are used. Or a module that has
> nothing referenced. I appreciate the unused variables diganostics but
> would like the same for the variable grouping constructs.
ftncheck does this, for f77 of course.
<snip>
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
|
|
|
|
|