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


Groups > comp.lang.c > #42444

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

From David Brown <david.brown@hesbynett.no>
Newsgroups comp.lang.c
Subject Re: Table of "safe" methods to suppress "unused parameter" warnings?
Date 2014-04-01 10:16 +0200
Organization A noiseless patient Spider
Message-ID <lhdslm$sfm$1@dont-email.me> (permalink)
References (5 earlier) <87d2h2lm5p.fsf@dpt-info.u-strasbg.fr> <lhbl31$sld$1@dont-email.me> <warnings-20140331154620@ram.dialup.fu-berlin.de> <878urqnf6j.fsf@bazspaz.fatphil.org> <20140331161218.168@kylheku.com>

Show all headers | View raw


On 01/04/14 01:37, Kaz Kylheku wrote:
> On 2014-03-31, Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:
>> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>> True, but without any standard way of handling this then "(void) x;" is
>>>> the simplest and clearest way to have a statement with no effect.
>>>
>>>   Actually (I admit that I might take your sentence out of its
>>>   context here), when »x« is a variable, »x;« is the simplest
>>>   and clearest way to have a statement with no effect that
>>>   mentions this variable »x«, and, otherwise, »;« is the
>>>   simplest and clearest way to have a statement with no effect.
>>
>> 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.
> 
> The intention of (void) E is exactly the opposite: it states
> that E is to be evaluated for its side effects, and its side effects
> only---the result value is to be discarded.
> 
> This is spelled out in ISO C.
> 
>   6.3.2.2 void
> 
>   The (nonexistent) value of a void expression (an expression that has type
>   void) shall not be used in any way, and implicit or explicit conversions
>   (except to void) shall not be applied to such an expression. If an expression
>   of any other type is evaluated as a void expression, its value or designator
>   is discarded.  (A void expression is evaluated for its side effects.)
> 
> If x is an ordinary non-volatile-qualified variable, then  "x;" has no effect,
> and discards its value, and so does "(void) x;".  They are both equivalent and
> nonsensical. Both of them in fact leave x unused. If a non-volatile-qualified
> variable has its value accessed, but that value is immediately discarded,
> that abstract use of the variable can be optimized away.
> 
> Compilers which translate "(void) x;" into the meaning "pretend that x is
> used, and thereby shut up unused variable warning" are doing exactly the
> following: they are giving a useful meaning to a piece of nonsense that serves
> no purpose and can be optimized away completely. It is similar to a conforming
> extension which gives meaning to bad syntax, except that this is
> good-albeit-useless syntax.
> 
> This behavior is a hack; it should not be codified as standard behavior.
> Neither x; nor (void) x; should constitute a use of x, unless x is volatile.
> Thre should be no special case if that is the only evaluation of x in
> a function body.

This is all true - but since these warning messages are from the
implementation (the standards do not require them), it is perfectly
reasonable for the method of disabling them to be an
implementation-dependent "hack".  The hack here is a good choice, in
that "(void) x;" is clearly and unambiguously asking to do nothing with
x (except evaluate it, if x is volatile).  It leads to no extra object
code, is ignored by any compiler other than its effects on warning
messages, and seems to give the desired "disable the warning" effect on
most  compilers (I haven't yet seen a counterexample).

> 
> The right place for asserting that "the non-use of this variable can be
> ignored"  is in the declaration of that variable. A nice way to achieve
> that is the omission of a name.
> 

I'd agree that this makes sense too - and things like gcc's "unused"
attribute do the same thing, but in a compiler-dependent way.  Putting
the "this is not used" marker in the declaration also opens for more
optimisation, if the compiler can trust it (which it cannot for "unnamed
parameters", but could for explicitly marked unused parameters).

> Common Lisp gets this right:
> 
>   (defun foo (x y)
>     (declare (ignore x) (ignorable y))
>      ...)
> 
> Declare ignore means that "x is not used in the body; this is on purpose,
> please don't warn about this".  If the declaration is a lie---x is in fact used
> in the body---then there can be a diagnostic!
> 
> Declare ignorable means that "If x is not used in the body, that is deliberate;
> please don't warn about it".  In that case, x may appear, and no diagnostic
> is issued.
> 
> Ignorable is convenient for macros which might conditionally generate some
> piece of code that uses a parameter, or might not. They can be simplified
> by not having to conditionally add the declaration.
> 
> 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) { ... }
> 
> If we ignore it; it needs no name. (In Lisp it does because the symbol
> is a positional place holder in the lambda list).
> 

That would be nice - no doubts there.  But I won't hold my breath
waiting for it to reach the C standards!

In the meantime, you can at least do this:

#if defined(__GNUC__)
#define ignorable __attribute__((unused))
#else
#define ignorable
#endif

Back to comp.lang.c | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

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

csiph-web