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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#44811

On 2014-05-22, Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:
>> Common Lisp gets this right:
>> 
>>   (defun foo (x y)
>
> Doesn't look like omission of a name to me.
>
>>     (declare (ignore x) (ignorable y))
>
> That's not asserting that non-use can be ignored at the
> point declaration of the variable either. Both of the 
> things you've been positive about are not being demonstrated
> here.

That is the spot where declarations go in that language: a special
(declare ...) expression which is the first thing that is enclosed
in the binding construct. (Though possibly preceded by a docstring,
in the case of a function or method definition.)

It's vaguely analogous to old style C:

  int func(x, y)
  int x;
  int y;
  {
  }

The "int y" is the point of declaration of the variable, together
with the enclosure of y in the (x, y) list.

>> This would be nice to have in C:
>> 
>>   void foo(ignore int x, ignorable int y) { ... }
>> 
>> perhaps in optional conjunction with omission of the name:
>> 
>>   void foo(ignore int, ignorable int y) { ... }
>
> It gets complex because of type semantics though. In a family of

Given that, already:

   void foo(const int);
   void foo(int);

are exactly the same function type, in spite of const being a
real type qualifier, I don't see a problem.

> function pointers, what if some of the parameters are ignored for
> some of the functions - are they the same type?

Of course they are the same type; this has nothing to do with type.

Not every attribute which is syntactically a qualifier has to actually
be a semantic type qualifier.

It could be, syntactically, a storage class keyword also, since declarations
like "ignorable int * ignorable p" do not make sense.

>> If we ignore it; it needs no name. (In Lisp it does because the symbol
>> is a positional place holder in the lambda list).
>
> Again, your view of "need" isn't shared universally.

Omitting the name works well in C++, which has a large community of users.

> share it with the compiler, but sometimes redundancy is good
> for humans to aid understanding.

What C++ giveth, C++ taketh away: the complete definition of a hello world
class with a non-inlined constructor and destructor requires the class name to
be written a whopping seven times.

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

#42442

On 01/04/14 01:31, Stefan Ram wrote:
> Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
>> But it's the "(void)" part that most clearly says "this is
>> not supposed to do have no effect", IMHO. The intention is
>> not to just have no effect, it's to be clearly deliberate too.
> 
>   For an int variable »x«, I cannot see any hint in
> 
> x;
> 
>   that says that the author wants this to have an effect.
>   Therefore, I must assume that he does not want it to
>   have an effect. I do not know what (void) adds to this.
> 

It is not a human reader we want to convince here, it is the compiler
and its warnings.  A plain "x" will likely trigger a warning, such as
"statement with no effect" in gcc (assuming, of course, you have a high
level of warnings enabled).  These warnings are to help spot accidents
or typos - if the compiler sees just "x", it guesses that you have made
a mistake in your code.

It is the same thing as gcc warning on "if (x = y) ...", but giving no
warning on "if ((x = y)) ... ".  It assumes the first version to be a
typo (with "=" instead of "=="), but the second version to be a
deliberate indication that you know what you are doing.

> (int)x;
> 
>   means that »(int)x« is supposed to have an int value. So
> 
> (void)x;
> 
>   means that it is not supposed to have a /value/! A cast
>   has nothing to do with /effects/ but with /values/.
> 
>   Another example:
> 
> printf( "a" );
> 
>   prints »a«. Now I take your way of showing that it is
>   »not supposed to do have no effect«:
> 
> (void)printf( "a" );
> 
>   . What happens? Surprise! It still has the same effect!
>   So when (void) cannot impede the effect here, how is it to
>   »clearly say "this is not supposed to do have no effect"«?
> 

Indeed - the "(void)" cast is not there to make the compiler do nothing
- there was nothing for it to do in the first place (except evaluate x -
something the compiler only needs to do if x is volatile, and in that
case x is evaluated even when cast to void).  It is just there to tell
the compiler that you /really/ mean do nothing with x, and therefore it
should not issue a warning.

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

#42391

David Brown wrote:
> On 30/03/14 22:31, Ian Collins wrote:
>> Tim Rentsch wrote:
>>> Ian Collins <ian-news@hotmail.com> writes:
>>>
>>>> mathog 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:
>>>>
>>>> I wonder why C doesn't just follow C++ and allow unnamed parameters?
>>>
>>> Assuming for the sake of discussion that C did this, it
>>> still doesn't solve the problem, because sometimes you
>>> want the parameter name there but still have it not used,
>>> eg, when a function body has multiple definitions under
>>> control of a C preprocessor conditional.
>>
>> I disagree.  Allowing unnamed parameters would address the exact problem
>> stated in the question.  I don't see how multiple definitions under
>> control of a C preprocessor conditional would make a difference.  If an
>> "unused" parameter is used in the function body, you have a bug waiting
>> to happen.  It would be better to have it unnamed to allow the compiler
>> to spot the mistake.
>>
>> If you turn the argument on its head, why does C require parameters to
>> be named?  There doesn't appear to be any logical reason for this rule.
>
> I disagree (at least a bit) here - I don't see any reason to have
> unnamed parameters in C.  If the parameter is completely useless, then
> it should be removed entirely - if not, then the name is part of the
> documentation for the function's interface.  Just because it is not used
> in this particular version of the implementation of the function, does
> not mean it should not be named.

How so?  Consider for example a device driver interface that uses a 
struct of function pointers (a pretty common case).  All divers use the 
same struct, but not all divers require all of the parameters that are 
passed.  Having the parameter unnamed clearly documents that it is unused.

> And the solution to the original problem is nothing more dramatic than
> "(void) x;", which is neither hard to write nor hard to understand.

True, but it is ugly.  What possible harm could unnamed parameters cause?

> In C++, I can think of a situation where unnamed parameters make sense -
> you might want a function that requires you to have an object of a
> particular class but does not care about the contents.  This can be used
> to give compile-time checking of constraints.

Unnamed parameters are quite common in C++, probably more common than 
cases where they would be useful in C.  While the potential uses aren't 
a common in C, the feature would still be a useful, cost free, addition.


-- 
Ian Collins

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

#42396

On 31/03/14 12:17, Ian Collins wrote:
> David Brown wrote:
>> On 30/03/14 22:31, Ian Collins wrote:
>>> Tim Rentsch wrote:
>>>> Ian Collins <ian-news@hotmail.com> writes:
>>>>
>>>>> mathog 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:
>>>>>
>>>>> I wonder why C doesn't just follow C++ and allow unnamed parameters?
>>>>
>>>> Assuming for the sake of discussion that C did this, it
>>>> still doesn't solve the problem, because sometimes you
>>>> want the parameter name there but still have it not used,
>>>> eg, when a function body has multiple definitions under
>>>> control of a C preprocessor conditional.
>>>
>>> I disagree.  Allowing unnamed parameters would address the exact problem
>>> stated in the question.  I don't see how multiple definitions under
>>> control of a C preprocessor conditional would make a difference.  If an
>>> "unused" parameter is used in the function body, you have a bug waiting
>>> to happen.  It would be better to have it unnamed to allow the compiler
>>> to spot the mistake.
>>>
>>> If you turn the argument on its head, why does C require parameters to
>>> be named?  There doesn't appear to be any logical reason for this rule.
>>
>> I disagree (at least a bit) here - I don't see any reason to have
>> unnamed parameters in C.  If the parameter is completely useless, then
>> it should be removed entirely - if not, then the name is part of the
>> documentation for the function's interface.  Just because it is not used
>> in this particular version of the implementation of the function, does
>> not mean it should not be named.
> 
> How so?  Consider for example a device driver interface that uses a
> struct of function pointers (a pretty common case).  All divers use the
> same struct, but not all divers require all of the parameters that are
> passed.  Having the parameter unnamed clearly documents that it is unused.
> 

After this and Alain's posts, I have changed my mind.  You are of course
correct that in cases where functions have to fit a particular type, you
can easily get parameters that have no function and would be best left
unnamed.

>> And the solution to the original problem is nothing more dramatic than
>> "(void) x;", which is neither hard to write nor hard to understand.
> 
> True, but it is ugly.  What possible harm could unnamed parameters cause?

In the case where a function has a parameter but the current
implementation does not use it, I think it is best to name it and mark
it as unused (either by something like the gcc attribute, if that is
portable enough for the code, or by (void) x).  That makes it clear that
the parameter is reserved for a purpose.

In the case where a function has extra parameters just to make it fit a
common signature, then unnamed parameters would seem better, as you are
then saying that these parameters are not really part of the function.

> 
>> In C++, I can think of a situation where unnamed parameters make sense -
>> you might want a function that requires you to have an object of a
>> particular class but does not care about the contents.  This can be used
>> to give compile-time checking of constraints.
> 
> Unnamed parameters are quite common in C++, probably more common than
> cases where they would be useful in C.  While the potential uses aren't
> a common in C, the feature would still be a useful, cost free, addition.
> 

We already pay the "cost" of unnamed parameters - they are legal in
function declarations, letting people write unhelpful declarations (like
"extern int foo(int, int)").  So yes, it would be a free feature with at
least some good uses.

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

#42401

On 2014-03-31, David Brown <david.brown@hesbynett.no> wrote:
> I disagree (at least a bit) here - I don't see any reason to have
> unnamed parameters in C.

C already has support for unnamed parameters, namely in function declarations.

 int foo(char *, int);

> If the parameter is completely useless, then
> it should be removed entirely

In large-scale software development, we do not always have complete freedom to
remove any function parameter we want whenever we feel that it's not necessary.

Calls to a function may be in code that we don't want to, or cannot modify.

Functions may be called through function pointers, which have many
implementations, some of which don't need to use some parameters.

C++ has unnamed parameters; so supporting unnamed parameters improves
C and C++ compatibility.

> And the solution to the original problem is nothing more dramatic than
> "(void) x;", which is neither hard to write nor hard to understand.

I believe that (void) x is not universally recognized by all compilers as a
use of a non-volatile x.

Also, C didn't always have void; don't we have C++ to thank for that?

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

#42958

Ian Collins <ian-news@hotmail.com> writes:

> Tim Rentsch wrote:
>> Ian Collins <ian-news@hotmail.com> writes:
>>
>>> mathog 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:
>>>
>>> I wonder why C doesn't just follow C++ and allow unnamed parameters?
>>
>> Assuming for the sake of discussion that C did this, it
>> still doesn't solve the problem, because sometimes you
>> want the parameter name there but still have it not used,
>> eg, when a function body has multiple definitions under
>> control of a C preprocessor conditional.
>
> I disagree.  Allowing unnamed parameters would address the exact
> problem stated in the question.  I don't see how multiple
> definitions under control of a C preprocessor conditional would
> make a difference.  If an "unused" parameter is used in the
> function body, you have a bug waiting to happen.  It would be
> better to have it unnamed to allow the compiler to spot the
> mistake.

A simplified example of the scenario I was thinking of is, eg,

    int
    set_device_mode( int x, int y ){
      #if PLATFORM_X
        return  platform_x_syscall( x, y );
      #else
        UNUSED(y);
        return  common_syscall( x );
      #endif
    }

Note that the function interface is chosen to be platform
independent so callers don't have to fool around with #if,
etc.  (As it happens a code base I was working on recently
has lots of such CPP conditionals, so naturally an example
along these lines occurred to me right away.)

> If you turn the argument on its head, why does C require
> parameters to be named?  There doesn't appear to be any logical
> reason for this rule.

I don't know if there is or isn't, but I was deliberately trying
to avoid such questions because they don't change what I was
saying, namely, that allowing unnamed parameters in function
definitions does not by itself solve the problem of needing
something like UNUSED() [even considering the question just for
unused function parameters].

<editorial>
Probably it would be okay to to allow unnamed parameters, but IMO
it would be bad to _require_ that any unused parameter also be
unnamed, eg, by having a mandatory diagnostic for such cases.
</editorial>


>> And there are
>> variables besides parameter names that are important to
>> mark UNUSED in certain circumstances.
>
> I assume you are referring to unused function return values?  I
> don't see how this is relevant to the original question.

I will plead no contest on this one.  I took the original
posting as motivation to discuss the general problem of
avoiding "not used" diagnostics, not just for function
parameters.  Personally I think it makes sense to discuss
the question more generally than just function parameters,
but I admit many or perhaps most people were considering
only the more restricted domain.

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

#43428

On Tuesday, 15 April 2014 14:26:10 UTC+3, Tim Rentsch  wrote:
> Ian Collins <ian-news@hotmail.com> writes:
> 
> > Tim Rentsch wrote:
> >> Ian Collins <ian-news@hotmail.com> writes:
> >>
> >>> mathog 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:
> >>>
> >>> I wonder why C doesn't just follow C++ and allow unnamed parameters?
> >>
> >> Assuming for the sake of discussion that C did this, it
> >> still doesn't solve the problem, because sometimes you
> >> want the parameter name there but still have it not used,
> >> eg, when a function body has multiple definitions under
> >> control of a C preprocessor conditional.
> >
> > I disagree.  Allowing unnamed parameters would address the exact
> > problem stated in the question.  I don't see how multiple
> > definitions under control of a C preprocessor conditional would
> > make a difference.  If an "unused" parameter is used in the
> > function body, you have a bug waiting to happen.  It would be
> > better to have it unnamed to allow the compiler to spot the
> > mistake.
> 
> A simplified example of the scenario I was thinking of is, eg,
> 
>     int
>     set_device_mode( int x, int y ){
>       #if PLATFORM_X
>         return  platform_x_syscall( x, y );
>       #else
>         UNUSED(y);
>         return  common_syscall( x );
>       #endif
>     }

I have seen similar situation without preprocessor slicing:

     int
     do_something( int x, int y ){
         // y is reserved for postponed feature; must be 0 now
         unused(y);
         assert(y == 0); 

         // further code does not use y
         // ...
         return  something;
     }

When 'NDEBUG' is defined then there may be warning without
that 'unused'.

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

#43433

Öö Tiib <ootiib@hot.ee> writes:
[...]
> I have seen similar situation without preprocessor slicing:
>
>      int
>      do_something( int x, int y ){
>          // y is reserved for postponed feature; must be 0 now
>          unused(y);
>          assert(y == 0); 
>
>          // further code does not use y
>          // ...
>          return  something;
>      }
>
> When 'NDEBUG' is defined then there may be warning without
> that 'unused'.

There is "preprocessor slicing" here; it's just hidden by the
definition of the assert() macro.  Since y is used in an assert(),
it's not really unused.

You could write this as:

    #ifdef NDEBUG
    unused(y);
    #endif
    assert(y == 0);

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#42339

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.

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

#42393

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.

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".  An endless supply
of suggestions of macros that mess around with "x" in weird ways does
not help anyone.

(Tool-specific annotations such as gcc "unused" attribute or PC-Lint
annotations can be a useful addition if you use those particular tools.)

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

#42394

On 03/31/2014 07:26 AM, David Brown wrote:
...
> 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".

Because they're looking for something that will work on compilers where
(void)x doesn't work. It could "not work" in two different ways: the
compiler is too dumb to avoid wasting time evaluating 'x', even though
nothing is done with the value of that expression, or it is too "smart"
to be fooled by (void)x, and still complains either about x being
unused, or about (void)x not doing anything.

I don't know of any such compilers, but neither have I bothered testing.
I have a policy of not changing my code to turn off non-mandatory
diagnostics unless I agree that they have detected an actual problem for
which the re-write is an appropriate solution.

(void)x is one of the possibilities considered by mathog, yet it's not
the only one he considered, so I presume he found at least one platform
where it didn't work.
-- 
James Kuyper

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

#42397

On 31/03/14 13:37, James Kuyper wrote:
> On 03/31/2014 07:26 AM, David Brown wrote:
> ...
>> 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".
> 
> Because they're looking for something that will work on compilers where
> (void)x doesn't work. It could "not work" in two different ways: the
> compiler is too dumb to avoid wasting time evaluating 'x', even though
> nothing is done with the value of that expression, or it is too "smart"
> to be fooled by (void)x, and still complains either about x being
> unused, or about (void)x not doing anything.
> 

Compilers that are too dumb to avoid wasting time evaluating x in
"(void) x" are going to be even worse with the other proposed solutions.


> I don't know of any such compilers, but neither have I bothered testing.
> I have a policy of not changing my code to turn off non-mandatory
> diagnostics unless I agree that they have detected an actual problem for
> which the re-write is an appropriate solution.
> 
> (void)x is one of the possibilities considered by mathog, yet it's not
> the only one he considered, so I presume he found at least one platform
> where it didn't work.
> 

It is on his list, but there has been no indication from anyone that
there are real-world compilers that have trouble with it.  If there
/are/ compilers that give warnings on "(void) x" (either complaining
about x being unused, or the statement not having an effect), then it
could be useful to hear about it.  And perhaps it would be useful to
report it as a bug or "enhancement request" to the compiler vendor -
warnings that are too enthusiastic can hide /real/ problems in code.

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

#43066

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.

> 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).

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

#43072

In article <kfnvbu6buv8.fsf@x-alumni2.alumni.caltech.edu>,
Tim Rentsch  <txr@alumni.caltech.edu> wrote:
...
>Concern for such systems is not on my radar, and I would
>recommend to other people it not be on their radar either.

That's not the CLC way.  Kiki (and the rest of the Kikians) will not
approve.  Expect your clique membership card to be revoked.

>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.

That's not the CLC way.  Kiki (and the rest of the Kikians) will not
approve.  Expect your clique membership card to be revoked.

>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.

That's not the CLC way.  Kiki (and the rest of the Kikians) will not
approve.  Expect your clique membership card to be revoked.

-- 
"Insisting on perfect safety is for people who don't have the balls to live
in the real world."

    - Mary Shafer, NASA Ames Dryden -

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

#43079

Tim Rentsch <txr@alumni.caltech.edu> writes:
> David Brown <david.brown@hesbynett.no> writes:
[...]
>>> 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 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).

We have an assertion that compilers "tend to" warn about several
forms of the UNUSED() macro.

Is there a concrete example of a compiler that complains about
((void)x)?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#43653

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> David Brown <david.brown@hesbynett.no> writes:
> [...]
>>>> 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 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).
>
> We have an assertion that compilers "tend to" warn about several
> forms of the UNUSED() macro.

I read that paragraph as offering a statement of his beliefs
rather than making an allegation of fact.  So I would probably
say "opinion" rather than "assertion".

> Is there a concrete example of a compiler that complains about
> ((void)x)?

I have a dim memory of seeing a warning out of gcc for this when
used in some unusual context.  In fact seeing that is part of
what originally prompted me to look for an alternate form of
expression for a macro like UNUSED.

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.

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

#43654

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)); }

-- 
The scent of awk programmers is a lot more attractive to women than
the scent of perl programmers.

      (Mike Brennan, quoted in the "GAWK" manual)

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

#45759

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.  So getting a complaint about it is a positive, not a
negative.

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

#45768

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".

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.

Phil
-- 
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]

#45769

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.

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

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

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

csiph-web