Avoiding "unused dummy argument" warnings.
Paul van Delst
I'm preparing to change to use finalisers in type definitions. While I'm waiting for f2003
compilers, I'm doing stuff like the following (assuming the TR15581 is implemented):
TYPE :: CRTM_Cloud_type
! Dimension values
INTEGER :: n_Layers = 0
! Cloud type
INTEGER :: Type = NO_CLOUD
! Cloud state variables
REAL(fp), ALLOCATABLE :: Effective_Radius(:) ! Units are microns
REAL(fp), ALLOCATABLE :: Effective_Variance(:) ! Units are microns^2
REAL(fp), ALLOCATABLE :: Water_Content(:) ! Units are kg/m^2
END TYPE CRTM_Cloud_type
with its destruction routine:
ELEMENTAL SUBROUTINE CRTM_Cloud_Destroy( Cloud )
! Arguments
TYPE(CRTM_Cloud_type), INTENT(OUT) :: Cloud
! The following is just to avoid
! "unused dummy argument"
! warning during compilation
IF ( .NOT. CRTM_Cloud_Associated( Cloud ) ) RETURN
END FUNCTION CRTM_Cloud_Destroy
If I rely on the INTENT(OUT) of the above argument to do all the
reinitialisation/deallocation, all I really need to do is:
ELEMENTAL SUBROUTINE CRTM_Cloud_Destroy( Cloud )
TYPE(CRTM_Cloud_type), INTENT(OUT) :: Cloud
END FUNCTION CRTM_Cloud_Destroy
right?
If so, does anyone have any idea how does one avoid "Unused dummy argument" warnings from
compilers in this case?
I don't want to turn off the warnings altogether because I do want to track down "real"
unused arguments in other cases.
Thanks for any info/ideas.
cheers,
paulv
Colin Watters
"Paul van Delst" <paul.v...@noaa.gov> wrote in message
news:hcnapn$p3v$1...@news.woc.noaa.gov...
>
<snip>
> If I rely on the INTENT(OUT) of the above argument to do all the
> reinitialisation/deallocation, all I really need to do is:
>
> ELEMENTAL SUBROUTINE CRTM_Cloud_Destroy( Cloud )
> TYPE(CRTM_Cloud_type), INTENT(OUT) :: Cloud
> END FUNCTION CRTM_Cloud_Destroy
>
> right?
>
> If so, does anyone have any idea how does one avoid "Unused dummy
> argument" warnings from
> compilers in this case?
>
Whenever I want to re-initialize a structure, ... I know the above works
(though I'm not sure about the 'elemental' bit) but I find it more
self-explanatory to do this:
ELEMENTAL SUBROUTINE CRTM_Cloud_Destroy( Cloud )
TYPE(CRTM_Cloud_type), INTENT(OUT) :: Cloud
TYPE(CRTM_Cloud_type) :: empty_Cloud
cloud = empty_cloud
END FUNCTION CRTM_Cloud_Destroy
... which ought to prevent the compiler warnings as well.
--
Qolin
Email: my qname at domain dot com
Domain: qomputing
Paul van Delst
Yeah, that a good idea. At first I was worried the assignment would generate a lot of
copying (assuming the allocatable components are many) but they're not allocated!
Good one, thanks.
cheers,
paulv
Richard Maine
> If I rely on the INTENT(OUT) of the above argument to do all the
> reinitialisation/deallocation, all I really need to do is:
>
> ELEMENTAL SUBROUTINE CRTM_Cloud_Destroy( Cloud )
> TYPE(CRTM_Cloud_type), INTENT(OUT) :: Cloud
> END FUNCTION CRTM_Cloud_Destroy
>
> right?
>
> If so, does anyone have any idea how does one avoid "Unused dummy
> argument" warnings from compilers in this case?
>
> I don't want to turn off the warnings altogether because I do want to
> track down "real" unused arguments in other cases.
Bitch at the vendors in question. That really is just plain a compiler
bug. Yes, I know it isn't a bug in terms of standard conformance. The
standard doesn't prohibit compilers from giving all kinds of silly
warnings. Don't get me wrong; I'm a big fan of compiler warnings about
things that are actually wrong. But there is nothing wrong here. The
intent(out) with default initialization essentially counts as a "use",
or at least it ought to for the purpose of such warnings; if it doesn't,
then that counts as a compiler bug in my book.
This strikes me as somewhat like the compiler warnings (which I have
seen) that bitch at pretty much every character assignment statement to
warn you that it might act just like character assignment statements
always do (truncate and/or pad). Next thing will be a compiler warning
for every floatting point operation to warn that rounding might happen.
:-(
Be wary of workarounds that are worse than the problem. I have seen
people suggest workarounds for simillar spurious "variable unused"
warnings that take perfectly valid and sensible code and turn it into
code that is invalid and potentially buggy - just because the good code
generated a compiler warning, but the questionable code didn't.
For example, workarounds to this kind of problem sometimes involve
referencing variables that might not be defined. And remember, for a
derived type variable to be defined, all of its components must be
defined. Just because you have default initialization of some
components, that doesn't necessarily mean that all of them are defined.
That's a kind of bug that can "hide" for a long time until it bites you.
I don't think it a good tradeoff to introduce the potential of problems
like that just to avoid a spurious compiler warning for perfectly fine
code. Kick the vendor to fix the compiler instead.
Compiler warnings can be helpful at times, but they are not the ultimate
arbiter of code correctness. It is a good general rule to fix things
that the compiler warns about. But as a general rule, I tend to not like
taking general rules as absolutes. :-)
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
Paul van Delst
> Paul van Delst <paul.v...@noaa.gov> wrote:
>
>> If I rely on the INTENT(OUT) of the above argument to do all the
>> reinitialisation/deallocation, all I really need to do is:
>>
>> ELEMENTAL SUBROUTINE CRTM_Cloud_Destroy( Cloud )
>> TYPE(CRTM_Cloud_type), INTENT(OUT) :: Cloud
>> END FUNCTION CRTM_Cloud_Destroy
>>
>> right?
>>
>> If so, does anyone have any idea how does one avoid "Unused dummy
>> argument" warnings from compilers in this case?
>>
>> I don't want to turn off the warnings altogether because I do want to
>> track down "real" unused arguments in other cases.
>
> Bitch at the vendors in question. That really is just plain a compiler
> bug. Yes, I know it isn't a bug in terms of standard conformance. The
> standard doesn't prohibit compilers from giving all kinds of silly
> warnings. Don't get me wrong; I'm a big fan of compiler warnings about
> things that are actually wrong. But there is nothing wrong here. The
> intent(out) with default initialization essentially counts as a "use",
> or at least it ought to for the purpose of such warnings; if it doesn't,
> then that counts as a compiler bug in my book.
That makes sense - but mere mortals such as I can't tell without help what definitively
constitutes "use" in all cases. And, as I am eternally grateful to the vendor in question
(the gfortran crew), I won't bitch.... I'll just whinge a little. :o)
This may also be fixed in a later release that I haven't downloaded. (I'm still on 4.4.0
20090219)
> This strikes me as somewhat like the compiler warnings (which I have
> seen) that bitch at pretty much every character assignment statement to
> warn you that it might act just like character assignment statements
> always do (truncate and/or pad). Next thing will be a compiler warning
> for every floatting point operation to warn that rounding might happen.
> :-(
Isn't there a switch for that? :o)
Seriously, though, a lot of my code and other code I work on is, unfortunately, replete
with unused dummy arguments so in my case I want the warning for the "real" cases of
unused dummy args so I can eliminate them.
In my defense, it's generally a case of planning and coding for something that never
eventuated (in direct opposition to the YAGNI principle. :o)
cheers,
paulv
Richard Maine
> Richard Maine wrote:
> > Bitch at the vendors in question.
> I won't bitch.... I'll just whinge a little. :o)
Of course, that's what I really meant. Even if it were a compiler you
paid for, starting out by being bitchy isn't usually the best way to get
results. (Well, if you are a major customer who paid a *LOT* of money,
that's a different story, but a few hundred dollars, or even a few
thousand, doesn't give you that kind of leverage).
> Seriously, though, a lot of my code and other code I work on is,
> unfortunately, replete with unused dummy arguments so in my case I want
> the warning for the "real" cases of unused dummy args so I can eliminate
> them.
>
> In my defense, it's generally a case of planning and coding for something
> that never eventuated (in direct opposition to the YAGNI principle. :o)
I have zillions of unused dummy arguments in my code as well. In my
case, it is provisions for features that might well be used. I have lots
of subroutines that are "hooks" for users of my programs - quite a lot
of them actually; it is inherent in the role that some of the programs
play. I provide do-nothing stub versions of the subroutines. If the user
wants to take advantage of the feature in question, he provides his own
version, which replaces my do-nothing one.
I'm even prepared to argue that it is consistent with an object-oriented
design approach. (Once I found out what some of the buzz words meant, I
realized I had been doing things at least close to object oriented
design before I had any idea what that meant). A subroutine call is
likely to mean "go take this action on yourself; here's the data you can
use to do it". Not all kinds of objects will end up using all of the
allowed data.
Tobias Burnus
> Richard Maine wrote:
>>> I don't want to turn off the warnings altogether because I do want to
>>> track down "real" unused arguments in other cases.
>>
>> Bitch at the vendors in question. That really is just plain a compiler
>> bug. Yes, I know it isn't a bug in terms of standard conformance. The
>> standard doesn't prohibit compilers from giving all kinds of silly
>> warnings. Don't get me wrong; I'm a big fan of compiler warnings about
>> things that are actually wrong. But there is nothing wrong here. The
>> intent(out) with default initialization essentially counts as a "use",
>> or at least it ought to for the purpose of such warnings; if it doesn't,
>> then that counts as a compiler bug in my book.
Getting the warning always there were the user makes mistakes even if it
is valid code and printing no warning where the code is valid and as
indented, is kind of hard. I am sure that turning this warning of will
hide some problem someone has in a real-world program. (Warning point to
potential issues, they do not mean that there is always a real problem.)
I filled now a gfortran PR, but I am not 100% sure when to issue this
warning and when not. Only for non-derived types and non-allocatables?
Or also for derived types without allocatable components and default
initializer? Or ...? (Note: The warning is not enabled by default.)
>> This strikes me as somewhat like the compiler warnings (which I have
>> seen) that bitch at pretty much every character assignment statement to
>> warn you that it might act just like character assignment statements
>> always do (truncate and/or pad).
Well, sometimes such warning (for truncation, not for padding - and not
enabled by default) can be useful. For instance in initialization
expressions:
character(len=4) :: str='hello'
1
Warning: CHARACTER expression at (1) is being truncated (5/4)
While for "str = 'string'" in the execution part of the program a
warning is less helpful. For assigning a character literal to a
PARAMETER, one could argue that warning for padding could be also useful ;-)
>> Next thing will be a compiler warning for every floatting point operation
>> to warn that rounding might happen. :-(
Why not if the warning is not on by default :-) Sometimes I wished
people would get a "Warning: You are doing unsafe math here, read the
Goldberg paper" - and would indeed read the article.
Tobias
steve
>
> >> If I rely on the INTENT(OUT) of the above argument to do all the
> >> reinitialisation/deallocation, all I really need to do is:
>
> >> ELEMENTAL SUBROUTINE CRTM_Cloud_Destroy( Cloud )
> >> TYPE(CRTM_Cloud_type), INTENT(OUT) :: Cloud
> >> END FUNCTION CRTM_Cloud_Destroy
>
> >> right?
>
> >> If so, does anyone have any idea how does one avoid "Unused dummy
> >> argument" warnings from compilers in this case?
>
> >> I don't want to turn off the warnings altogether because I do want to
> >> track down "real" unused arguments in other cases.
>
> > Bitch at the vendors in question. That really is just plain a compiler
> > bug. Yes, I know it isn't a bug in terms of standard conformance. The
> > standard doesn't prohibit compilers from giving all kinds of silly
> > warnings. Don't get me wrong; I'm a big fan of compiler warnings about
> > things that are actually wrong. But there is nothing wrong here. The
> > intent(out) with default initialization essentially counts as a "use",
> > or at least it ought to for the purpose of such warnings; if it doesn't,
> > then that counts as a compiler bug in my book.
>
> That makes sense - but mere mortals such as I can't tell without help what definitively
> constitutes "use" in all cases. And, as I am eternally grateful to the vendor in question
> (the gfortran crew), I won't bitch.... I'll just whinge a little. :o)
>
> This may also be fixed in a later release that I haven't downloaded. (I'm still on 4.4.0
> 20090219)
When one asks nicely, others tend to be sympathetic to your request.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41918
Note, I have a patch testing at the moment that will silence gfortran
for
a dummy argument of derived type with default initialization.
--
steve
dpb
> Am 02.11.2009 22:59, schrieb Paul van Delst:
>> Richard Maine wrote:
>>> Next thing will be a compiler warning for every floatting point operation
>>> to warn that rounding might happen. :-(
>
> Why not if the warning is not on by default :-) Sometimes I wished
> people would get a "Warning: You are doing unsafe math here, read the
> Goldberg paper" - and would indeed read the article.
Maybe include the paper itself as the warning message? <gd&r>
--
Richard Maine
> Am 02.11.2009 22:59, schrieb Paul van Delst:
> > Richard Maine wrote:
> >>> I don't want to turn off the warnings altogether because I do want to
> >>> track down "real" unused arguments in other cases.
> >>
> >> But there is nothing wrong here. The
> >> intent(out) with default initialization essentially counts as a "use",
> >> or at least it ought to for the purpose of such warnings; if it doesn't,
> >> then that counts as a compiler bug in my book.
>
> I filled now a gfortran PR, but I am not 100% sure when to issue this
> warning and when not. Only for non-derived types and non-allocatables?
> Or also for derived types without allocatable components and default
> initializer? Or ...? (Note: The warning is not enabled by default.)
Well, I'm not a compiler-writer type, so I'm not sure my answer is
necessarily the best approach. But the way I'd think about it is not
that the warning is somehow turned off, but rather that the combination
of intent(out) and default initialization counts as a "use". Seems to me
that's really much the way that it acts - like an assignment statement
that is automatically inserted. So I'd think it should trigger the same
kinds of things that the assignment statement would in terms of flagging
the variable as having been used.
And allocatable components seem simillar to me. In fact, I think of an
allocatable component as being so much like a default initialization
that I wish one could express it that way explicitly, but one can't.
> >> This strikes me as somewhat like the compiler warnings (which I have
> >> seen) that bitch at pretty much every character assignment statement to
> >> warn you that it might act just like character assignment statements
> >> always do (truncate and/or pad).
>
> Well, sometimes such warning (for truncation, not for padding - and not
> enabled by default) can be useful. For instance in initialization
> expressions:
>
> character(len=4) :: str='hello'
> 1
> Warning: CHARACTER expression at (1) is being truncated (5/4)
>
> While for "str = 'string'" in the execution part of the program a
> warning is less helpful.
Yes. That seem sreasonable to me. I'm talking about warnings that
happened with almost every assignment, including ones like
character :: line*80, field*16
integer :: field_start, field_end
.... code to find the field start and end values.
field = line(field_start:field_end)
Getting a warning for cases like that is just plain annoying in my book
- particularly so when you could not turn off that particular warning
without turning off all warnings. That meant I could not get any
warnings at all without being buried amidst hundreds of spurious ones. I
suppose I could have used "grep -v" to filter them out, but that's a
pain. Yes, I recall a compiler like that. (I forget which one; think I
might recall which one it was, but I'm not even close to sure, so I'll
avoid names so as to avoid a false accusation.)
Paul van Delst
>
> When one asks nicely, others tend to be sympathetic to your request.
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41918
I must have asked *really* nicely. :o) This bug was reported by Tobias between me leaving
work and getting home last night!
> Note, I have a patch testing at the moment that will silence gfortran
> for a dummy argument of derived type with default initialization.
Barganza. Thanks very much.
It's not really said enough, but the effort being made on gfortran is really appreciated
by this end-user. (I hope that doesn't come across as insincere what with it being tacked
onto the end of a bug-fix request :o)
Thanks Steve and Tobias.
cheers,
paulv
Dick Hendrickson
and variables.
real pi
pi = 3.14152653D0
is almost for sure a mistake, just as your str(1:4) = 'HELLO'
is almost always a mistake. Whereas, assigning variables
is more likely to be the right thing.
Dick Hendrickson