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

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

Table of "safe" methods to suppress "unused parameter" warnings?

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

Contents

  Table of "safe" methods to suppress "unused parameter" warnings? mathog <dmathog@gmail.com> - 2014-03-26 09:54 -0700
    Re: Table of "safe" methods to suppress "unused parameter" warnings? Barry Schwarz <schwarzb@dqel.com> - 2014-03-26 10:55 -0700
      Re: Table of "safe" methods to suppress "unused parameter" warnings? Keith Thompson <kst-u@mib.org> - 2014-03-26 11:13 -0700
      Re: Table of "safe" methods to suppress "unused parameter" warnings? Javier Lopez <j.lopezg@aol.com> - 2014-03-26 19:45 +0100
        Re: Table of "safe" methods to suppress "unused parameter" warnings? Kaz Kylheku <kaz@kylheku.com> - 2014-03-26 19:55 +0000
    Re: Table of "safe" methods to suppress "unused parameter" warnings? mathog <dmathog@gmail.com> - 2014-03-26 17:01 -0700
      Re: Table of "safe" methods to suppress "unused parameter" warnings? Javier Lopez <j.lopezg@aol.com> - 2014-03-27 01:46 +0100
        Re: Table of "safe" methods to suppress "unused parameter" warnings? Thomas Jahns <jahns@idontlikespam.dkrz.de> - 2014-03-27 09:34 +0100
          Re: Table of "safe" methods to suppress "unused parameter" warnings? gazelle@shell.xmission.com (Kenny McCormack) - 2014-03-27 10:52 +0000
          Re: Table of "safe" methods to suppress "unused parameter" warnings? David Brown <david.brown@hesbynett.no> - 2014-03-27 13:10 +0100
    Re: Table of "safe" methods to suppress "unused parameter" warnings? Ian Collins <ian-news@hotmail.com> - 2014-03-27 21:50 +1300
      Re: Table of "safe" methods to suppress "unused parameter" warnings? Tim Rentsch <txr@alumni.caltech.edu> - 2014-03-29 17:32 -0700
        Re: Table of "safe" methods to suppress "unused parameter" warnings? Ian Collins <ian-news@hotmail.com> - 2014-03-31 09:31 +1300
          Re: Table of "safe" methods to suppress "unused parameter" warnings? David Brown <david.brown@hesbynett.no> - 2014-03-31 11:31 +0200
            Re: Table of "safe" methods to suppress "unused parameter" warnings? Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-03-31 12:04 +0200
              Re: Table of "safe" methods to suppress "unused parameter" warnings? David Brown <david.brown@hesbynett.no> - 2014-03-31 13:55 +0200
                Re: Table of "safe" methods to suppress "unused parameter" warnings? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2014-04-01 02:04 +0300
                  Re: Table of "safe" methods to suppress "unused parameter" warnings? Kaz Kylheku <kaz@kylheku.com> - 2014-03-31 23:37 +0000
                    Re: Table of "safe" methods to suppress "unused parameter" warnings? David Brown <david.brown@hesbynett.no> - 2014-04-01 10:16 +0200
                    Re: Table of "safe" methods to suppress "unused parameter" warnings? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2014-05-22 13:10 +0300
                      Re: Table of "safe" methods to suppress "unused parameter" warnings? Kaz Kylheku <kaz@kylheku.com> - 2014-05-22 12:05 +0000
                  Re: Table of "safe" methods to suppress "unused parameter" warnings? David Brown <david.brown@hesbynett.no> - 2014-04-01 09:59 +0200
            Re: Table of "safe" methods to suppress "unused parameter" warnings? Ian Collins <ian-news@hotmail.com> - 2014-03-31 23:17 +1300
              Re: Table of "safe" methods to suppress "unused parameter" warnings? David Brown <david.brown@hesbynett.no> - 2014-03-31 14:05 +0200
            Re: Table of "safe" methods to suppress "unused parameter" warnings? Kaz Kylheku <kaz@kylheku.com> - 2014-03-31 15:24 +0000
          Re: Table of "safe" methods to suppress "unused parameter" warnings? Tim Rentsch <txr@alumni.caltech.edu> - 2014-04-15 04:26 -0700
            Re: Table of "safe" methods to suppress "unused parameter" warnings? Öö Tiib <ootiib@hot.ee> - 2014-04-23 07:31 -0700
              Re: Table of "safe" methods to suppress "unused parameter" warnings? Keith Thompson <kst-u@mib.org> - 2014-04-23 08:45 -0700
    Re: Table of "safe" methods to suppress "unused parameter" warnings? Tim Rentsch <txr@alumni.caltech.edu> - 2014-03-29 17:21 -0700
      Re: Table of "safe" methods to suppress "unused parameter" warnings? David Brown <david.brown@hesbynett.no> - 2014-03-31 13:26 +0200
        Re: Table of "safe" methods to suppress "unused parameter" warnings? James Kuyper <jameskuyper@verizon.net> - 2014-03-31 07:37 -0400
          Re: Table of "safe" methods to suppress "unused parameter" warnings? David Brown <david.brown@hesbynett.no> - 2014-03-31 14:12 +0200
        Re: Table of "safe" methods to suppress "unused parameter" warnings? Tim Rentsch <txr@alumni.caltech.edu> - 2014-04-18 07:00 -0700
          Re: Table of "safe" methods to suppress "unused parameter" warnings? gazelle@shell.xmission.com (Kenny McCormack) - 2014-04-18 15:02 +0000
          Re: Table of "safe" methods to suppress "unused parameter" warnings? Keith Thompson <kst-u@mib.org> - 2014-04-18 08:58 -0700
            Re: Table of "safe" methods to suppress "unused parameter" warnings? Tim Rentsch <txr@alumni.caltech.edu> - 2014-04-27 08:11 -0700
              Re: Table of "safe" methods to suppress "unused parameter" warnings? gazelle@shell.xmission.com (Kenny McCormack) - 2014-04-27 15:26 +0000
                Re: Table of "safe" methods to suppress "unused parameter" warnings? Tim Rentsch <txr@alumni.caltech.edu> - 2014-06-10 08:30 -0700
                  Re: Table of "safe" methods to suppress "unused parameter" warnings? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2014-06-11 00:57 +0300
                    Re: Table of "safe" methods to suppress "unused parameter" warnings? Ike Naar <ike@iceland.freeshell.org> - 2014-06-10 22:12 +0000
                      Re: Table of "safe" methods to suppress "unused parameter" warnings? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2014-06-11 20:25 +0300
                    Re: Table of "safe" methods to suppress "unused parameter" warnings? Martin Shobe <martin.shobe@yahoo.com> - 2014-06-10 18:59 -0500
                    Re: Table of "safe" methods to suppress "unused parameter" warnings? Tim Rentsch <txr@alumni.caltech.edu> - 2014-06-11 21:22 -0700
              Re: Table of "safe" methods to suppress "unused parameter" warnings? Kaz Kylheku <kaz@kylheku.com> - 2014-04-28 01:40 +0000
          Re: Table of "safe" methods to suppress "unused parameter" warnings? David Brown <david.brown@hesbynett.no> - 2014-04-19 17:52 +0200
    Re: Table of "safe" methods to suppress "unused parameter" warnings? Siri Crews <chine.bleu@yahoo.com> - 2014-06-11 02:04 -0700

Page 3 of 3 — ← Prev page 1 2 [3]

#45799

Ike Naar <ike@iceland.freeshell.org> writes:

> On 2014-06-10, Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:
> > I don't the the unused or otherwise nature of the parameter to be
> > in any way connected to whether it was passed in via a register or
> > not, so cannot support your "even sillier".
> 
> Parse error.

s/the/see/

-- 
Religion is too important a matter to its devotees to be a subject of 
ridicule. If they indulge in absurdities, they are to be pitied rather
than ridiculed. -- Immanuel Kant (1724-1804), lecture at Konigsberg, 1775

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

#45772

On 6/10/2014 4:57 PM, Phil Carmody wrote:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> gazelle@shell.xmission.com (Kenny McCormack) writes:
>>> In article <kfny4yqkdtj.fsf@x-alumni2.alumni.caltech.edu>,
>>> Tim Rentsch  <txr@alumni.caltech.edu> wrote:
>>> ...
>>>> By the way, for defining UNUSED, it's safer to use an expression
>>>> that takes the address of x, such as (void)&x, in case x happens
>>>> to be volatile qualified.
>>>
>>> /* Oops! */
>>> int foo(register int a) { (void) &a;return a; }
>>>
>>> main() { printf("foo(10) = %d\n",foo(10)); }
>>
>> Not Oops but Thank you.  These days it's silly to use 'register'
>> at all, but even sillier to use it for a variable that is marked
>> UNUSED.
>
> I don't the the unused or otherwise nature of the parameter to be
> in any way connected to whether it was passed in via a register or
> not, so cannot support your "even sillier".

I'll agree that using "register" for an unused parameter is no sillier 
than using "register" on a used parameter. What I find silly is trying 
to mark a parameter that is used (see the return statement) as unused.

[snip]

Martin Shobe

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

#45836

Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> gazelle@shell.xmission.com (Kenny McCormack) writes:
>> > In article <kfny4yqkdtj.fsf@x-alumni2.alumni.caltech.edu>,
>> > Tim Rentsch  <txr@alumni.caltech.edu> wrote:
>> > ...
>> >>By the way, for defining UNUSED, it's safer to use an expression
>> >>that takes the address of x, such as (void)&x, in case x happens
>> >>to be volatile qualified.
>> >
>> > /* Oops! */
>> > int foo(register int a) { (void) &a;return a; }
>> >
>> > main() { printf("foo(10) = %d\n",foo(10)); }
>> 
>> Not Oops but Thank you.  These days it's silly to use 'register'
>> at all, but even sillier to use it for a variable that is marked
>> UNUSED. 
>
> I don't the the unused or otherwise nature of the parameter to be
> in any way connected to whether it was passed in via a register or
> not, so cannot support your "even sillier".

Do we have a miscommunication?  I'm not talking about whether
an argument is passed in a register but only whether the 'register'
keyword is used.  The latter has no bearing on the former.  (Fine
point:  in principle it could, under particular circumstances of
optimization, but it general it does not, notably when the call
and the definition are in different TU's and separately compiled.)

> But in the context of function pointers, where calling conventions
> are immutable, and as long as your compiler is intelligent enough
> to honour your demands, if a function doesn't want to use a
> parameter passed in, then that's only its business.  You seem to
> have a no-functions-are-ever-called-via-function-pointers mindset.

Are you laboring under a misconception?  The presence or absence of
'register' in a parameter declaration has no effect on the
function's type (or pointer-to-function's type), type compatibility,
or the definedness of calling through a pointer-to-function.  It is
perfectly legal to use a pointer-to-function type, either with or
without a 'register' attached to a given parameter, and use it to
call functions that do use 'register' in their prototypes and also
functions that do not use 'register' in their prototypes.  Likewise
there is nothing wrong with declaring a function without 'register'
and defining it with 'register', or vice versa.  There is no effect
on the calling semantics, whether the function is called directly
or through a pointer-to-function.  (In fact all function calls occur
through a pointer-to-function, because of the rules for automatic
conversion of function types.)

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

#43691

On 2014-04-27, Tim Rentsch <txr@alumni.caltech.edu> wrote:
> By the way, for defining UNUSED, it's safer to use an expression
> that takes the address of x, such as (void)&x, in case x happens
> to be volatile qualified.

If the macro needs to add the & operator, it can easily
do that.

Show me the macro which takes away an unwanted & from an expression.

The unembellished name of the variable is what any macro needs to generate
whatever it needs to.

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

#43128

On 18/04/14 16:00, Tim Rentsch wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 30/03/14 01:21, Tim Rentsch wrote:
>>> mathog <dmathog@gmail.com> writes:
>>>
>>>> Sometimes the same parameter list must be passed to a lot of
>>>> different functions, and some of those will not use all of the
>>>> parameters, resulting in some compilers emitting "unused
>>>> parameter" warnings.  Here are all of the methods I have found
>>>> so far for suppressing these [snipping the first kind;  the
>>>> second kind] of UNUSED's is more general and it is applied
>>>> within the function like:
>>>>
>>>>     int function (x){
>>>>        UNUSED(x);
>>>>
>>>> #define UNUSED(x) ((void)x)
>>>> #define UNUSED(x) x=x
>>>> #define UNUSED(x) ( *(volatile typeof(x) *)&(x) = (x); )
>>>> #define UNUSED(x) if(x);
>>>>
>>>> Unfortunately the members of the second set tend to convert the
>>>> "unused parameter" message into some variant of a "this line
>>>> does nothing" message on other compilers.  For instance, that is
>>>> what the "x=x" form, which works with gcc does when clang sees
>>>> it.  [snip]
>>>
>>> I suggest trying this form:
>>>
>>>      #define UNUSED(x)  ( (void) (0 ? 0 : &(x)) )
>>>
>>> or perhaps this alternate definition:
>>>
>>>      #define UNUSED(x)  ( (void) (0 ? &(x) : &(x)) )
>>>
>>> I'm interested to hear what you results you get if you
>>> try these with different compilers.
>>
>> Such code may be inefficient on some compilers (and with some
>> options) - if "x" has been passed in a register, the compiler may
>> copy it onto the stack in order for it to have an address, even
>> though the address is not used.
>
> Concern for such systems is not on my radar, and I would
> recommend to other people it not be on their radar either.  Any
> developer using such a lame compiler who isn't motivated enough
> or competent enough to discover even one of the obvious ways
> around the problem deserves to get bad results.  We're talking
> about compiler technology that is nearly 50 years old, and
> originally implemented in machines with 256 K of RAM, including
> the OS, and no virtual memory.  Bad tools should be gotten rid
> of, not catered to.

Perhaps that is the case in your little corner of the C programming 
world.  But there are plenty of microcontrollers around where the choice 
of tools is limited, and where compilers are often quite poor (or where 
good quality compilers are extremely expensive), and where a pointless 
waste of cycles and code space is something to be avoided.

I would say that if you are often worrying about small performance 
issues, then you should probably change toolchains and/or processor. 
Mostly you should be concentrating on writing good C code, and let the 
compiler turn it into efficient object code.  But there is no reason for 
making something as simple as a "unused parameter" marker into a waste 
of time and space.

>
>> I have yet to see any reason to why anyone would need something
>> other than "(void) x;" as a way to say "do nothing with x".
>> [snip]
>
> Then apparently you haven't been paying attention, since one was
> given in the first message of the thread, and quoted both in my
> reply and your response to it (and shown again above).
>

Actually, I /have/ been paying attention - and I have seen (and 
re-quoted) the vague and so far unjustified concern that "(void) x" 
/might/ not be enough to suppress "unused parameter" warnings, or 
/might/ trigger other warnings.  Despite the length of this thread, 
there have been no concrete examples.  So until someone can show a 
definite case where the compiler gives an unused parameter warning on x, 
gives the same (or another warning) on "(void) x", and gives no warning 
and no extra code on some weird do-nothing-in-a-complex-way statement, 
then I will continue to recommend "(void) x" as the general solution to 
this problem.

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

#45781

In article <lgv0nu$8g1$1@dont-email.me>, mathog <dmathog@gmail.com> wrote:

> Sometimes the same parameter list must be passed to a lot of different 
> functions, and some of those will not use all of the parameters, 
> resulting in some compilers emitting "unused parameter" warnings.  Here 
> are all of the methods I have found so far for suppressing these:

Have you ever considerred you're fighing a fight that doesn't need to be fought. 
First of all there's no reason to list all possible warnings one particular 
compiler project dreamed up as as questionable usage. Nor do you have accept 
their opinions about what is questionable usage.

A function's parameter list is what is called an interface. The function body is 
what is called the implementation. Recently (in maybe the 1960s or the 1970s) it 
was realised the interface can be disconnected from the implementation. You 
could even have a library of implementations changing day by day, but as long as 
the interfaces remained the same, library clients would be unaffected by changes 
in the implementations. One recent innovation was too essentially link libraries 
as a program runs so that library implementations could change run by run 
without a program's awareness.

One consequence is to generalise interface. An interface might include 
parameters that were once needed by an old implementation or are speculated to 
be necessary to a future implementation. Because interfaces and implementations 
could be decoupled, an interface with more information than one implementation 
could support alternate implementation that do need that information. The 
interface client really doesn't have to worry about implementation details.


Turn off the bloody unused parameters warning and start worrying about real 
problems instead of invented trivialities.

-- 
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.
'I desire mercy, not sacrifice.'
Icke's razor: Given two equally plausible explanations, choose the weirder.

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

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

csiph-web