Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #8547 > unrolled thread

Not used parameter: how to disable the warning

Back to article view | Back to comp.lang.c

Contents

  Not used parameter: how to disable the warning pozz <pozzugno@gmail.com> - 2011-07-22 00:35 +0200
    Re: Not used parameter: how to disable the warning Ian Collins <ian-news@hotmail.com> - 2011-07-22 10:47 +1200
      Re: Not used parameter: how to disable the warning "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-07-22 02:13 -0700
      Re: Not used parameter: how to disable the warning Kenneth Brody <kenbrody@spamcop.net> - 2011-07-22 12:04 -0400
        Re: Not used parameter: how to disable the warning Ian Collins <ian-news@hotmail.com> - 2011-07-23 09:34 +1200
    Re: Not used parameter: how to disable the warning Harald van Dijk <truedfx@gmail.com> - 2011-07-21 16:06 -0700
    Re: Not used parameter: how to disable the warning pete <pfiland@mindspring.com> - 2011-07-21 20:49 -0400
    Re: Not used parameter: how to disable the warning Geoff <geoff@invalid.invalid> - 2011-07-21 17:52 -0700
    Re: Not used parameter: how to disable the warning Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-07-21 20:52 -0400
    Re: Not used parameter: how to disable the warning Seebs <usenet-nospam@seebs.net> - 2011-07-22 02:51 +0000
    Re: Not used parameter: how to disable the warning rudolf <r.thered@gmail.com> - 2011-07-21 20:08 -0700
      Re: Not used parameter: how to disable the warning Ian Collins <ian-news@hotmail.com> - 2011-07-22 15:15 +1200
    Re: Not used parameter: how to disable the warning Ralf Damaschke <rwspam@gmx.de> - 2011-07-22 09:01 +0000
    Re: Not used parameter: how to disable the warning Roberto Waltman <usenet@rwaltman.com> - 2011-07-22 17:56 -0400

#8547 — Not used parameter: how to disable the warning

Is there a universal method (valid for all C compilers) that avoids the 
compiler to generate a warning about a not used parameter of a function?

I think it isn't because compiler warnings aren't regulated by the 
standard. So I'm wondering what could be the best or the better methods 
to face this situation.

I tried with the following on my compiler:

   int sum(int a, int b, int unused) {
     unused;
     return a + b;
   }

but it works only with a low level of warnings. Otherwise I can do:

   int sum(int a, int b, int unused) {
     unused = unused;
     return a + b;
   }

but it generates an unuseful instruction without optimization.

What do you use for that goal?

[toc] | [next] | [standalone]

#8550

On 07/22/11 10:35 AM, pozz wrote:
> Is there a universal method (valid for all C compilers) that avoids the
> compiler to generate a warning about a not used parameter of a function?
>
> I think it isn't because compiler warnings aren't regulated by the
> standard. So I'm wondering what could be the best or the better methods
> to face this situation.
>
> I tried with the following on my compiler:
>
>     int sum(int a, int b, int unused) {
>       unused;
>       return a + b;
>     }
>
> but it works only with a low level of warnings. Otherwise I can do:
>
>     int sum(int a, int b, int unused) {
>       unused = unused;
>       return a + b;
>     }
>
> but it generates an unuseful instruction without optimization.
>
> What do you use for that goal?

Luckily neither of the compilers I use complain about the first form 
(with our without the unused; line).

I guess this points to another useful C++ feature that could easily be 
added to C (allowing an unused parameter name to be omitted):

int sum(int a, int b, int )
{
   return a + b;
}

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#8570

On Jul 22, 12:47 am, Ian Collins <ian-n...@hotmail.com> wrote:
> On 07/22/11 10:35 AM, pozz wrote:
>
>
>
>
>
>
>
>
>
> > Is there a universal method (valid for all C compilers) that avoids the
> > compiler to generate a warning about a not used parameter of a function?
>
> > I think it isn't because compiler warnings aren't regulated by the
> > standard. So I'm wondering what could be the best or the better methods
> > to face this situation.
>
> > I tried with the following on my compiler:
>
> >     int sum(int a, int b, int unused) {
> >       unused;
> >       return a + b;
> >     }
>
> > but it works only with a low level of warnings. Otherwise I can do:
>
> >     int sum(int a, int b, int unused) {
> >       unused = unused;
> >       return a + b;
> >     }
>
> > but it generates an unuseful instruction without optimization.
>
> > What do you use for that goal?
>
> Luckily neither of the compilers I use complain about the first form
> (with our without the unused; line).
>
> I guess this points to another useful C++ feature that could easily be
> added to C (allowing an unused parameter name to be omitted):
>
> int sum(int a, int b, int )
> {
>    return a + b;
>
> }

That would be a very useful feature. Switching back and forth between
C and C++, i've often, implicitly, assumed it's already standard, was
been disappointed every time.

It's a much neater solution that casting to void or otherwise
introducing a null-statement.

[toc] | [prev] | [next] | [standalone]

#8586

On 7/21/2011 6:47 PM, Ian Collins wrote:
> On 07/22/11 10:35 AM, pozz wrote:
>> Is there a universal method (valid for all C compilers) that avoids the
>> compiler to generate a warning about a not used parameter of a function?
[...]
> I guess this points to another useful C++ feature that could easily be added
> to C (allowing an unused parameter name to be omitted):
>
> int sum(int a, int b, int )
> {
> return a + b;
> }

It's not always that simple.  Sometimes the parameter is unused only because 
of some #if.

int sum(int a, int b, int foo)
     {
#if USE_FOO
     DoSomething("sum",foo);
#endif
     return(a+b);
     }

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#8605

On 07/23/11 04:04 AM, Kenneth Brody wrote:
> On 7/21/2011 6:47 PM, Ian Collins wrote:
>> On 07/22/11 10:35 AM, pozz wrote:
>>> Is there a universal method (valid for all C compilers) that avoids the
>>> compiler to generate a warning about a not used parameter of a function?
> [...]
>> I guess this points to another useful C++ feature that could easily be added
>> to C (allowing an unused parameter name to be omitted):
>>
>> int sum(int a, int b, int )
>> {
>> return a + b;
>> }
>
> It's not always that simple.  Sometimes the parameter is unused only because
> of some #if.
>
> int sum(int a, int b, int foo)
>       {
> #if USE_FOO
>       DoSomething("sum",foo);
> #endif
>       return(a+b);
>       }

I would guess such cases are rare.  Anyway, they still don't negate the 
elegance of the solution.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#8551

On Jul 22, 12:35 am, pozz <pozzu...@gmail.com> wrote:
> Is there a universal method (valid for all C compilers) that avoids the
> compiler to generate a warning about a not used parameter of a function?

No, there isn't.

> I think it isn't because compiler warnings aren't regulated by the
> standard.

Right, the standard only gives some circumstances in which a
diagnostic is required, but compilers are free to warn for any and all
other invalid or valid constructs.

> So I'm wondering what could be the best or the better methods
> to face this situation.

The most common form I have seen, that works well in my experience but
is not universal, is to cast the parameter to void:

> I tried with the following on my compiler:
>
>    int sum(int a, int b, int unused) {
>      unused;

  (void) unused;

>      return a + b;
>    }
>
> but it works only with a low level of warnings.
>
> Otherwise I can do:
>
>    int sum(int a, int b, int unused) {
>      unused = unused;
>      return a + b;
>    }
>
> but it generates an unuseful instruction without optimization.

Plus a possible warning that you're assigning to unused, but ignoring
its result. Your first form, with or without a cast, is not likely to
generate any code at all.

[toc] | [prev] | [next] | [standalone]

#8554

pozz wrote:
> 
> Is there a universal method
> (valid for all C compilers) that avoids the
> compiler to generate a warning
> about a not used parameter of a function?

I don't know.
 
> I think it isn't because compiler warnings aren't regulated by the
> standard.

That makes sense to me.

> So I'm wondering what could be the best or the better methods
> to face this situation.
> 
> I tried with the following on my compiler:
> 
>    int sum(int a, int b, int unused) {
>      unused;
>      return a + b;
>    }
> 
> but it works only with a low level of warnings. Otherwise I can do:
> 
>    int sum(int a, int b, int unused) {
>      unused = unused;
>      return a + b;
>    }
> 
> but it generates an unuseful instruction without optimization.
> 
> What do you use for that goal?

You could try:

int 
sum(int a, int b, int unused) 
{
    return unused, a + b;
}

-- 
pete

[toc] | [prev] | [next] | [standalone]

#8556

On Fri, 22 Jul 2011 00:35:41 +0200, pozz <pozzugno@gmail.com> wrote:

>Is there a universal method (valid for all C compilers) that avoids the 
>compiler to generate a warning about a not used parameter of a function?
>

No, there is no universal method for all compilers. The compilers are
free to warn or not warn depending on warning level and what the
designers intend for their implementation.

>I think it isn't because compiler warnings aren't regulated by the 
>standard. So I'm wondering what could be the best or the better methods 
>to face this situation.
>

Microsoft warns about this at warning level 4. I think their intent is
to catch code where the programmer defined an argument to a function
but later dropped that parameter in the actual function body, a clue
that maybe the user could streamline his code. I have code where a
group of functions all need the same arguments but some use them all
and some don't.

>I tried with the following on my compiler:
>
>   int sum(int a, int b, int unused) {
>     unused;
>     return a + b;
>   }
>
>but it works only with a low level of warnings. Otherwise I can do:
>
>   int sum(int a, int b, int unused) {
>     unused = unused;
>     return a + b;
>   }
>
>but it generates an unuseful instruction without optimization.
>
>What do you use for that goal?

For Microsoft compilers you can turn off individual warnings with the
#pragma command in a header or in an individual translation unit,
usually by bracketing the code with push-pops of the warning state:

#pragma warning (push)
#pragma warning(disable : 4100)	// unreferenced formal parameter

int sum(int a, int b, int unused) {
    return a + b;
}
#pragma warning (pop)

Of course, massive use of this technique defeats the purpose of
warning levels and you might as well back it down to -W3 if you are
going to play this game.

[toc] | [prev] | [next] | [standalone]

#8557

On 7/21/2011 6:35 PM, pozz wrote:
> Is there a universal method (valid for all C compilers) that avoids the
> compiler to generate a warning about a not used parameter of a function?

     No, because a compiler is always permitted to issue diagnostics
about any random condition its implementors think of.  It cannot
refuse to translate a correct program simply because it's told you
"foo.c(37): E1943 Not tonight, I have a headache", but it's free to
issue the diagnostic anyhow.

> I think it isn't because compiler warnings aren't regulated by the
> standard. So I'm wondering what could be the best or the better methods
> to face this situation.

     The Standard does in fact regulate diagnostics, but the regulatory
burden is light.  Some transgressions are required to provoke
diagnostics, some are not (but may), and as mentioned above it is
entirely all right for the compiler to produce diagnostics even for
valid C programs.  (Warning about an unused `defualt:' label in a
`switch' statement, for example, is probably a Good Thing even when
the code is perfectly valid as it stands.)

     Another point is that the Standard speaks only of "diagnostics,"
not of "errors" and "warnings," nor of "errors" and "warnings" and
"stylistic abominations" and "queasy feelings."  Even a required
diagnostic need not prompt an implementation to refuse a program; it
can say "Syntax error: Proceeding as if there were a `,' here" and
translate the program anyhow.  (Exception: It must refuse a program
with a "live" `#error' directive.)

> I tried with the following on my compiler:
>
> int sum(int a, int b, int unused) {
> unused;
> return a + b;
> }
>
> but it works only with a low level of warnings. Otherwise I can do:
>
> int sum(int a, int b, int unused) {
> unused = unused;
> return a + b;
> }
>
> but it generates an unuseful instruction without optimization.
>
> What do you use for that goal?

     Some compilers will be quiet if you write `(void)unused;' to
"use" the unused parameter.  Others, unfortunately, will issue new
warnings of the "Statement with no effect" kind ...

     One possibility is to use a macro whose definition is tuned to
the particular compiler in use.  You'd write

	int sum(int a, int b, int unused) {
	    UNUSED(unused)
	    ...

and in a header file somewhere you'd have something like

	#ifdef _FROBOZZ_MAGIC_C_
	    #define UNUSED(x) _Pragma(x,__PARAM_UNUSED__)
	#elif defined _O_SAY_CAN_YOU_C_
	    #define UNUSED(x) /* empty */
	#else
	    /* Hope for the best ... */
	    #define UNUSED(x) void(x);
	#endif

This list of compiler-specific dodges can be updated as experience
dictates.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#8561

On 2011-07-21, pozz <pozzugno@gmail.com> wrote:
> What do you use for that goal?

	(void) unused;

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

#8562

In article <j0a9jt$7f0$1@nnrp.ngi.it>, pozz <pozzugno@gmail.com> wrote:

> Is there a universal method (valid for all C compilers) that avoids the 
> compiler to generate a warning about a not used parameter of a function?

Yes, there is.  Modify the function so that it takes only the parameters 
it uses.

> but it works only with a low level of warnings. Otherwise I can do:
> 
>    int sum(int a, int b, int unused) {
>      unused = unused;
>      return a + b;
>    }

why not this?
int sum(int a, int b)

[toc] | [prev] | [next] | [standalone]

#8563

On 07/22/11 03:08 PM, rudolf wrote:
> In article<j0a9jt$7f0$1@nnrp.ngi.it>, pozz<pozzugno@gmail.com>  wrote:
>
>> Is there a universal method (valid for all C compilers) that avoids the
>> compiler to generate a warning about a not used parameter of a function?
>
> Yes, there is.  Modify the function so that it takes only the parameters
> it uses.

That isn't always possible, especially where the function is used as a 
callback or anywhere else a function address is assigned to a function 
pointer.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#8569

pozz <pozzugno@gmail.com> wrote:

> Is there a universal method (valid for all C compilers) that
> avoids the compiler to generate a warning about a not used
> parameter of a function? 

Some compilers also observe the old "lint" directive
/*ARGSUSED*/
written directly before the function definition.

-- Ralf

[toc] | [prev] | [next] | [standalone]

#8609

 pozz  wrote:
>Is there a universal method (valid for all C compilers) that avoids the 
>compiler to generate a warning about a not used parameter of a function?
>
>What do you use for that goal?

For parameters - 
If the compiler allows it, disable the warning for that (and only
that) condition.

If not, and if I don't care about generating additional code
(generally I do):

void  *blackhole;    /* global, one per project, defined as */
                            /* extern in a common header file */

void f(int abused, int unused)
{
    blackhole = &unused;
    ...
}

Better if hidden in a macro:

#define USE(something) (blackhole = &something)

void f(int abused, int unused)
{
    USE(unused);
	...
}

For functions -
If they are really not used, remove them or comment them out.
Otherwise, a trick similar to the one above.
--
Roberto Waltman

[ Please reply to the group.
  Return address is invalid ]

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web