Suppressing "Parameter not used" Warning

Discussion in 'C Programming' started by Dave Hansen, Oct 3, 2005.

  1. Dave Hansen

    Dave Hansen Guest

    Please note crosspost.

    Often when writing code requiring function pointers, it is necessary
    to write functions that ignore their formal parameters. For example,
    a state machine function might take a status input, but a certain
    error-handling state might ignore it:

    typedef void (*State_Fn)(uint8_t);

    void error_state(uint8_t status)
    {
    NOT_USED(status);

    /* code handling error but ignoring status */
    }

    In another group, a poster asked about defining a macro NOT_USED as
    shown above to quiet the compiler warning. His suggested
    implementation was

    #define NOT_USED(p) ((void)(p))

    In this particular case, he noted the compiler he was using would
    generate the warning even in the presence of this macro. I suggested
    he use

    #define NOT_USED(p) ((p)=(p))

    He was pleased that it worked, but was concerned that the former
    implementation was more widely supported, and that the latter might
    generate executable code. I for one had never seen the former before,
    though I've often seen the latter (usually not hidden behind a macro),
    and I've never seen it actually generate code. At least, not in the
    last ten years or so.

    So I'm curious. Which form (if either) is more common? Are there any
    implementations that will generate executable code for the latter?

    Thanks,
    -=Dave

    -=Dave
    --
    Change is inevitable, progress is not.
     
    Dave Hansen, Oct 3, 2005
    #1
    1. Advertising

  2. Dave Hansen

    pete Guest

    Dave Hansen wrote:
    >
    > Please note crosspost.
    >
    > Often when writing code requiring function pointers, it is necessary
    > to write functions that ignore their formal parameters. For example,
    > a state machine function might take a status input, but a certain
    > error-handling state might ignore it:
    >
    > typedef void (*State_Fn)(uint8_t);
    >
    > void error_state(uint8_t status)
    > {
    > NOT_USED(status);
    >
    > /* code handling error but ignoring status */
    > }
    >
    > In another group, a poster asked about defining a macro NOT_USED as
    > shown above to quiet the compiler warning. His suggested
    > implementation was
    >
    > #define NOT_USED(p) ((void)(p))
    >
    > In this particular case, he noted the compiler he was using would
    > generate the warning even in the presence of this macro. I suggested
    > he use
    >
    > #define NOT_USED(p) ((p)=(p))
    >
    > He was pleased that it worked, but was concerned that the former
    > implementation was more widely supported, and that the latter might
    > generate executable code.


    Non executable code tends to generate warnings.

    > I for one had never seen the former before,
    > though I've often seen the latter (usually not hidden behind a macro),
    > and I've never seen it actually generate code. At least, not in the
    > last ten years or so.
    >
    > So I'm curious. Which form (if either) is more common? Are there any
    > implementations that will generate executable code for the latter?


    In distributions file for a sort timing program
    my distribution function arguments are of this form:
    (e_type *array, size_t n, long unsigned *seed)

    but only some of them use the seed for a PRNG.

    Others are like this:

    void sorted(e_type *a, size_t n, long unsigned *seed)
    {
    a += n;
    while (n-- != 0) {
    (*--a).data = n;
    }
    seed;
    }

    So, I just make an expression statement out of seed
    and that seems to stop the warnings.

    --
    pete
     
    pete, Oct 3, 2005
    #2
    1. Advertising

  3. In comp.lang.c Dave Hansen <> wrote:

    > typedef void (*State_Fn)(uint8_t);


    > void error_state(uint8_t status)
    > {
    > NOT_USED(status);


    > /* code handling error but ignoring status */
    > }


    Why not just

    void error_state( uint8_t ) /* don't care about formal parameter */
    {
    /* code */
    }

    ? (I'm not enough of a guru to answer your real question.)

    --
    Christopher Benson-Manica | I *should* know what I'm talking about - if I
    ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
     
    Christopher Benson-Manica, Oct 3, 2005
    #3
  4. Dave Hansen

    Skarmander Guest

    Christopher Benson-Manica wrote:
    > In comp.lang.c Dave Hansen <> wrote:
    >
    >
    >> typedef void (*State_Fn)(uint8_t);

    >
    >
    >> void error_state(uint8_t status)
    >> {
    >> NOT_USED(status);

    >
    >
    >> /* code handling error but ignoring status */
    >> }

    >
    >
    > Why not just
    >
    > void error_state( uint8_t ) /* don't care about formal parameter */
    > {

    Because that's not legal C. If it were, we obviously wouldn't need any
    hacks. You can do this in prototypes; in C++ you can also do it in
    definitions. Not in C, however.

    S.
     
    Skarmander, Oct 3, 2005
    #4
  5. Dave Hansen

    Eric Sosman Guest

    Dave Hansen wrote On 10/03/05 10:13,:
    > Please note crosspost.
    >
    > Often when writing code requiring function pointers, it is necessary
    > to write functions that ignore their formal parameters. For example,
    > a state machine function might take a status input, but a certain
    > error-handling state might ignore it:
    >
    > typedef void (*State_Fn)(uint8_t);
    >
    > void error_state(uint8_t status)
    > {
    > NOT_USED(status);
    >
    > /* code handling error but ignoring status */
    > }
    >
    > In another group, a poster asked about defining a macro NOT_USED as
    > shown above to quiet the compiler warning. His suggested
    > implementation was
    >
    > #define NOT_USED(p) ((void)(p))
    >
    > In this particular case, he noted the compiler he was using would
    > generate the warning even in the presence of this macro. I suggested
    > he use
    >
    > #define NOT_USED(p) ((p)=(p))
    >
    > He was pleased that it worked, but was concerned that the former
    > implementation was more widely supported, and that the latter might
    > generate executable code. I for one had never seen the former before,
    > though I've often seen the latter (usually not hidden behind a macro),
    > and I've never seen it actually generate code. At least, not in the
    > last ten years or so.
    >
    > So I'm curious. Which form (if either) is more common? Are there any
    > implementations that will generate executable code for the latter?


    First, there is no sure-fire way to prevent compilers
    from issuing diagnostics. The compiler is entitled to
    grouse about anything it chooses, provided it accepts code
    that does not actually contravene the Standard. It can
    warn about spellnig errors in comennts, or about inconsistent
    indentation levels. The requirement "No warnings from any
    compiler" is not ultimately tenable.

    FWIW, the `(void)p' formulation seems to be widespread.
    Even if a compiler complains about it, a human reader will
    see immediately that it was in fact the programmer's intent
    that `p' remain unused -- the programmer may have made a
    mistake, but at least it was not one of simple inattention.

    I don't think `(p)=(p)' is a wonderful idea. If `p' is
    volatile the generated code must perform both the read and the
    write. If `p' is `const' the compiler is required to issue a
    diagnostic, so you're no better off than when you started --
    worse, if anything. Of course, `const'-qualified function
    parameters are fairly unusual and `volatile' parameters are
    exceedingly rare, but the possibilities exist.

    In any case, hiding the actual trickery behind a NOT_USED
    macro seems a good idea: you can re-#define NOT_USED as part
    of your adaptation to each new compiler that comes along,
    using whatever compiler-specific dodge seems to work best.

    --
     
    Eric Sosman, Oct 3, 2005
    #5
  6. In article <1128348834.7e34f2c71121565d6e8683d1777b7524@teranews>,
    Dave Hansen <> wrote:
    >
    > In another group, a poster asked about defining a macro NOT_USED as
    > shown above to quiet the compiler warning.


    An alternative would be to invoke the compiler using a flag or option
    that disables the unused variable/parameter warning.

    However, it's good practice to turn the warning back on every once
    in a while and see if any unexpected unused thingies have crept into
    the code.
     
    Anonymous 7843, Oct 3, 2005
    #6
  7. Dave Hansen

    David Brown Guest

    Dave Hansen wrote:
    > Please note crosspost.
    >
    > Often when writing code requiring function pointers, it is necessary
    > to write functions that ignore their formal parameters. For example,
    > a state machine function might take a status input, but a certain
    > error-handling state might ignore it:
    >
    > typedef void (*State_Fn)(uint8_t);
    >
    > void error_state(uint8_t status)
    > {
    > NOT_USED(status);
    >
    > /* code handling error but ignoring status */
    > }
    >
    > In another group, a poster asked about defining a macro NOT_USED as
    > shown above to quiet the compiler warning. His suggested
    > implementation was
    >
    > #define NOT_USED(p) ((void)(p))
    >
    > In this particular case, he noted the compiler he was using would
    > generate the warning even in the presence of this macro. I suggested
    > he use
    >
    > #define NOT_USED(p) ((p)=(p))
    >
    > He was pleased that it worked, but was concerned that the former
    > implementation was more widely supported, and that the latter might
    > generate executable code. I for one had never seen the former before,
    > though I've often seen the latter (usually not hidden behind a macro),
    > and I've never seen it actually generate code. At least, not in the
    > last ten years or so.
    >
    > So I'm curious. Which form (if either) is more common? Are there any
    > implementations that will generate executable code for the latter?
    >
    > Thanks,
    > -=Dave
    >
    > -=Dave


    I use the first version, a cast-to-void macro. It works fine for gcc
    (various ports).
     
    David Brown, Oct 3, 2005
    #7
  8. On 2005-10-03, David Brown <> wrote:

    >> #define NOT_USED(p) ((void)(p))
    >>[...]
    >> #define NOT_USED(p) ((p)=(p))
    >>[...]
    >>
    >> So I'm curious. Which form (if either) is more common? Are there any
    >> implementations that will generate executable code for the latter?


    > I use the first version, a cast-to-void macro. It works fine
    > for gcc (various ports).


    Very slightly OT, but I just use gcc's __attribute__((unused)).
    I realize it's not-portable to other compilers, but...

    1) In my applications so much of the code is platform-specific
    that it just doesn't matter.

    2) I've used nothing but gcc for embedded work for the past 6
    or 7 years anyway.

    --
    Grant Edwards grante Yow! Will the third world
    at war keep "Bosom Buddies"
    visi.com off the air?
     
    Grant Edwards, Oct 3, 2005
    #8
  9. In comp.lang.c Skarmander <> wrote:

    > Because that's not legal C. If it were, we obviously wouldn't need any
    > hacks. You can do this in prototypes; in C++ you can also do it in
    > definitions. Not in C, however.


    My apologies; I use C++, and this was a difference of which I was not
    aware. Thanks.

    --
    Christopher Benson-Manica | I *should* know what I'm talking about - if I
    ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
     
    Christopher Benson-Manica, Oct 3, 2005
    #9
  10. Dave Hansen

    Old Wolf Guest

    Dave Hansen wrote:
    > In another group, a poster asked about defining a macro NOT_USED as
    > shown above to quiet the compiler warning. His suggested
    > implementation was
    >
    > #define NOT_USED(p) ((void)(p))
    >
    > In this particular case, he noted the compiler he was using would
    > generate the warning even in the presence of this macro. I suggested
    > he use
    >
    > #define NOT_USED(p) ((p)=(p))
    >
    >
    > So I'm curious. Which form (if either) is more common? Are there
    > any implementations that will generate executable code for the latter?


    Yes, the compiler might warn that 'p' is assigned a value which
    is never used. And it might also warn about reading an uninitialized
    variable.

    One compiler I use has this definition:

    #define NOT_USED(junk) { (volatile typeof(junk))junk = junk; }
     
    Old Wolf, Oct 3, 2005
    #10
  11. "Old Wolf" <> writes:
    > Dave Hansen wrote:
    >> In another group, a poster asked about defining a macro NOT_USED as
    >> shown above to quiet the compiler warning. His suggested
    >> implementation was
    >>
    >> #define NOT_USED(p) ((void)(p))
    >>
    >> In this particular case, he noted the compiler he was using would
    >> generate the warning even in the presence of this macro. I suggested
    >> he use
    >>
    >> #define NOT_USED(p) ((p)=(p))
    >>
    >>
    >> So I'm curious. Which form (if either) is more common? Are there
    >> any implementations that will generate executable code for the latter?

    >
    > Yes, the compiler might warn that 'p' is assigned a value which
    > is never used. And it might also warn about reading an uninitialized
    > variable.


    In fact, strictly speaking, this could invoke undefined behavior if p
    really hasn't been initialized. Since it's a parameter (at least in
    the context intended by the OP), that would happen only if the caller
    passes an uninitialized value, so it would require some additional
    smarts by the compiler to detect the problem.

    On most real-world systems, this isn't going to cause any visible
    problems, but it's possible that certain pointer values can cause a
    trap when you try to load them into a register, even if there's no
    attempt to dereference the value. The same could apply to any type
    that can have trap representations.

    Hiding this behind a NOT_USED macro is a good idea. The definition of
    the macro can probably be made to vary depending on what system you're
    on, using the usual twisty maze of #ifdefs method.

    The ((p)=(p)) trick is ok if you make sure p is always initialized,
    even to a meaningless value.

    As others have mentioned, there is no portable way to control specific
    warnings that will work across implementations.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Oct 3, 2005
    #11
  12. In article <>,
    says...
    > Dave Hansen wrote:
    > > In another group, a poster asked about defining a macro NOT_USED as
    > > shown above to quiet the compiler warning. His suggested
    > > implementation was
    > >
    > > #define NOT_USED(p) ((void)(p))
    > >
    > > In this particular case, he noted the compiler he was using would
    > > generate the warning even in the presence of this macro. I suggested
    > > he use
    > >
    > > #define NOT_USED(p) ((p)=(p))
    > >
    > >
    > > So I'm curious. Which form (if either) is more common? Are there
    > > any implementations that will generate executable code for the latter?

    >
    > Yes, the compiler might warn that 'p' is assigned a value which
    > is never used. And it might also warn about reading an uninitialized
    > variable.
    >
    > One compiler I use has this definition:
    >
    > #define NOT_USED(junk) { (volatile typeof(junk))junk = junk; }
    >
    >

    Metrowerks Codewarrior has the

    #pragma unused (varname)

    construct to solve this problem. I'm surprised that other compilers
    don't have the same facility.

    Mark Borgerson
     
    Mark Borgerson, Oct 3, 2005
    #12
  13. Dave Hansen

    Thad Smith Guest

    Dave Hansen wrote:

    > Often when writing code requiring function pointers, it is necessary
    > to write functions that ignore their formal parameters. For example,
    > a state machine function might take a status input, but a certain
    > error-handling state might ignore it:
    >
    > typedef void (*State_Fn)(uint8_t);
    >
    > void error_state(uint8_t status)
    > {
    > NOT_USED(status);
    >
    > /* code handling error but ignoring status */
    > }
    >
    > In another group, a poster asked about defining a macro NOT_USED as
    > shown above to quiet the compiler warning. His suggested
    > implementation was
    >
    > #define NOT_USED(p) ((void)(p))
    >
    > In this particular case, he noted the compiler he was using would
    > generate the warning even in the presence of this macro.


    I have used a void cast for some compilers. For another, I was
    successful with

    #define UNUSED(x) if(x);

    Thad
     
    Thad Smith, Oct 4, 2005
    #13
  14. "David Brown" <> wrote in message
    news:43417a0a$...
    ....
    > > #define NOT_USED(p) ((void)(p))

    ....
    > I use the first version, a cast-to-void macro. It works fine for gcc
    > (various ports).


    Also: borland, watcom, a few less popilar ones. I don't remember about
    msvc++. Probably too.
    Alex
     
    Alexei A. Frounze, Oct 4, 2005
    #14
  15. "Thad Smith" <> wrote in message
    news:4341e5ff$0$27319$...
    ....
    > I have used a void cast for some compilers. For another, I was
    > successful with
    >
    > #define UNUSED(x) if(x);


    Nice, though some clever compiler could warn here whether or not you're sure
    it's what you intend to do, whether or not this code has any effect.

    Alex
     
    Alexei A. Frounze, Oct 4, 2005
    #15
  16. Dave Hansen

    David Brown Guest

    Mark Borgerson wrote:
    > In article <>,
    > says...
    >
    >>Dave Hansen wrote:
    >>
    >>>In another group, a poster asked about defining a macro NOT_USED as
    >>>shown above to quiet the compiler warning. His suggested
    >>>implementation was
    >>>
    >>> #define NOT_USED(p) ((void)(p))
    >>>
    >>>In this particular case, he noted the compiler he was using would
    >>>generate the warning even in the presence of this macro. I suggested
    >>>he use
    >>>
    >>> #define NOT_USED(p) ((p)=(p))
    >>>
    >>>
    >>>So I'm curious. Which form (if either) is more common? Are there
    >>>any implementations that will generate executable code for the latter?

    >>
    >>Yes, the compiler might warn that 'p' is assigned a value which
    >>is never used. And it might also warn about reading an uninitialized
    >>variable.
    >>
    >>One compiler I use has this definition:
    >>
    >> #define NOT_USED(junk) { (volatile typeof(junk))junk = junk; }
    >>
    >>

    >
    > Metrowerks Codewarrior has the
    >
    > #pragma unused (varname)
    >
    > construct to solve this problem. I'm surprised that other compilers
    > don't have the same facility.
    >
    > Mark Borgerson


    The trouble with such pragmas is that they are completely non-portable.
    As Grant Edwards said, gcc has an equivalent (using an attribute,
    which is gcc prefers over pragmas). Often non-portability is not a
    problem, since there are so many other non-portable aspects to typical
    embedded systems (and in the case of gcc, it is at least portable to a
    few dozen other gcc ports).
     
    David Brown, Oct 4, 2005
    #16
  17. Dave Hansen

    David Brown Guest

    Grant Edwards wrote:
    > On 2005-10-03, David Brown <> wrote:
    >
    >
    >>> #define NOT_USED(p) ((void)(p))
    >>>[...]
    >>> #define NOT_USED(p) ((p)=(p))
    >>>[...]
    >>>
    >>>So I'm curious. Which form (if either) is more common? Are there any
    >>>implementations that will generate executable code for the latter?

    >
    >
    >>I use the first version, a cast-to-void macro. It works fine
    >>for gcc (various ports).

    >
    >
    > Very slightly OT, but I just use gcc's __attribute__((unused)).
    > I realize it's not-portable to other compilers, but...
    >
    > 1) In my applications so much of the code is platform-specific
    > that it just doesn't matter.
    >
    > 2) I've used nothing but gcc for embedded work for the past 6
    > or 7 years anyway.
    >


    Also OT, but the warning that bugs me most with gcc is "warning: will
    never be executed" on code that gets removed by the optimiser. If I've
    written code that really cannot ever be executed, it's (almost
    certainly) a mistake, so I want the compiler to tell me. But on code
    like this:

    if (test()) {
    doThis();
    doThat();
    } else {
    doSomethingElse();
    doThat();
    }

    gcc will combine the two "doThat()" calls (which is good), and then warn
    that one of the "will never be executed", which is bad.

    If you know any good ideas to get working "will never be executed"
    warnings, even if it is "wait for gcc 4.1.x", I'd love to hear them.
     
    David Brown, Oct 4, 2005
    #17
  18. Dave Hansen

    Bill Davy Guest

    "Dave Hansen" <> wrote in message
    news:1128348834.7e34f2c71121565d6e8683d1777b7524@teranews...
    > Please note crosspost.
    >


    snip snip

    void error_state(uint8_t /* status */)

    I prefer to leave the argument there as it should make code easier to
    comprehend. Commenting it out does not need comments.
     
    Bill Davy, Oct 4, 2005
    #18
  19. Dave Hansen

    Flash Gordon Guest

    Bill Davy wrote:
    > "Dave Hansen" <> wrote in message
    > news:1128348834.7e34f2c71121565d6e8683d1777b7524@teranews...
    >
    >>Please note crosspost.

    >
    > snip snip
    >
    > void error_state(uint8_t /* status */)
    >
    > I prefer to leave the argument there as it should make code easier to
    > comprehend. Commenting it out does not need comments.


    As noted by an earlier poster, that is not valid for a C function
    definition (declaration yes, but not definition which is what was being
    discussed).

    If you want to discus what you do in C++ (or any language other than C)
    then please remove comp.lang.c from the crosspost.
    --
    Flash Gordon
    Living in interesting times.
    Although my email address says spam, it is real and I read it.
     
    Flash Gordon, Oct 4, 2005
    #19
  20. David Brown wrote:
    > if (test()) {
    > doThis();
    > doThat();
    > } else {
    > doSomethingElse();
    > doThat();
    > }
    >
    > gcc will combine the two "doThat()" calls (which is good), and then warn
    > that one of the "will never be executed", which is bad.
    >
    > If you know any good ideas to get working "will never be executed"
    > warnings, even if it is "wait for gcc 4.1.x", I'd love to hear them.


    Hmmm. I tried this with a couple of GCC versions at default
    and -O[23] optimization levels (cross and native) and saw no
    such warning. What options/versions are you using?

    --
    Michael N. Moran (h) 770 516 7918
    5009 Old Field Ct. (c) 678 521 5460
    Kennesaw, GA, USA 30144 http://mnmoran.org

    "So often times it happens, that we live our lives in chains
    and we never even know we have the key."
    The Eagles, "Already Gone"

    The Beatles were wrong: 1 & 1 & 1 is 1
     
    Michael N. Moran, Oct 4, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Elliot M. Rodriguez

    suppressing Submit command with a Delete button

    Elliot M. Rodriguez, Dec 16, 2003, in forum: ASP .Net
    Replies:
    4
    Views:
    448
    Elliot M. Rodriguez
    Dec 17, 2003
  2. =?Utf-8?B?S2VubmV0aCBQ?=

    Suppressing the URL in a asp.net app

    =?Utf-8?B?S2VubmV0aCBQ?=, Nov 4, 2004, in forum: ASP .Net
    Replies:
    7
    Views:
    713
    =?Utf-8?B?S2VubmV0aCBQ?=
    Dec 24, 2004
  3. Lax
    Replies:
    1
    Views:
    1,230
    Johan Poppe
    Feb 27, 2004
  4. filmil
    Replies:
    3
    Views:
    455
  5. Michael B Allen

    Suppressing Compiler Warning About Tricky Macro

    Michael B Allen, Jul 22, 2007, in forum: C Programming
    Replies:
    6
    Views:
    351
    Barry Schwarz
    Jul 22, 2007
Loading...

Share This Page