Re: (void)foo or __unused foo ?
On Jul 27, 2012, at 2:38 AM, Luigi Rizzo wrote:
>
> The alternative way to avoid an 'unused' warning from the compiler
> is an empty statement
>
> (void)foo;
>
> that the compiler hopefully optimizes away.
I learned the void-cast convention many years ago.
I used it throughout the libarchive code and have yet to
run into any problems. I always use it in exactly this form
(with the exact comment here) so that I can easily search
on it:
int foo(int a) {
(void) a; /* UNUSED */
…
}
I agree with PHK that it would be nice to express this
intent in a way that static checkers could verify. I also
agree that having static checkers interpret comments is Evil.
But I have yet to see any alternative that was as
straightforward and widely-supported as this one.
Every other viable alternative seems to require tangled
clumps of macros.
Tim
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: (void)foo or __unused foo ?
In message <20120727125134.ga58...@onelab2.iet.unipi.it>, Luigi Rizzo writes: >A comment might be used to explain the intention in even more detail: > > (void)foo; /* unused on XyBSD and Babbage-OS */ Comments are noise which compilers and static checkers cannot and should not examine. The intent should be expressed where compilers and static checkers can see it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: (void)foo or __unused foo ?
I'd rather see a compiler-interpretable "way" of doing this. You could always just use your own for now, until something comes along (like how many #define N(a) there are in the tree, until nitems showed up.) Ie: #define A_UNUSED_Tvoid (A_UNUSED_T) foo; That way (a) it's easy to change with a compile macro change, (b) if it ever clashes, it should be easy enough to rename without having to risk renaming fields you didn't want to, and (c) it's compiler-interpretable. I wonder if bde has any ideas on where a BSD "unused" hint could be stuffed.. Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: (void)foo or __unused foo ?
On Fri, Jul 27, 2012 at 11:20:48AM +, Poul-Henning Kamp wrote:
> In message <20120727093824.gb56...@onelab2.iet.unipi.it>, Luigi Rizzo writes:
>
> >The alternative way to avoid an 'unused' warning from the compiler
> >is an empty statement
> >
> > (void)foo;
>
> The thing I don't like about this form, is that it doesn't communicate
> your intention, only your action.
>
> Somewhere down my TODO list I have an item to propose instead:
>
> typedef void unused_t;
>
> int main(int argc, char **argv)
> {
>
> (unused_t)argc;
> (unused_t)argv;
> return (0);
> }
i certainly like this better, my only concern is that some other
platform might come with an incompatible usage of the name 'unused_t'
same as it happened for __unused, and we are back with the problem.
A comment might be used to explain the intention in even more detail:
(void)foo; /* unused on XyBSD and Babbage-OS */
cheers
luigi
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: (void)foo or __unused foo ?
In message <20120727093824.gb56...@onelab2.iet.unipi.it>, Luigi Rizzo writes:
>The alternative way to avoid an 'unused' warning from the compiler
>is an empty statement
>
> (void)foo;
The thing I don't like about this form, is that it doesn't communicate
your intention, only your action.
Somewhere down my TODO list I have an item to propose instead:
typedef void unused_t;
int main(int argc, char **argv)
{
(unused_t)argc;
(unused_t)argv;
return (0);
}
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: (void)foo or __unused foo ?
On 2012-07-27 11:38, Luigi Rizzo wrote: > In writing cross platform code I often have to deal with function > arguments or variables that are not used on certain platforms. > In FreeBSD:sys/cdefs.h we have > > #define __unused__attribute__((__unused__)) > > and in the kernel we tend to annotate with "__unused" such arguments > > int f(type foo __unused) > > However on linux __unused is not a standard macro, and is often > used as a variable or field name in standard headers, so introducing > our __unused macro breaks compilation there. Hm, Linux seems to use __unused for padding in structs, and as the name (!!) of unused parameters in prototypes. :( It uses the following for unused attributes: #define __maybe_unused __attribute__((unused)) #define __always_unused __attribute__((unused)) The former seems to be used much more throughout the Linux sources, I count 243 instances of it in my copy, as opposed to just 9 of the latter. I don't really understand the rationale (if any) for two different defines, though. > The alternative way to avoid an 'unused' warning from the compiler > is an empty statement > > (void)foo; > > that the compiler hopefully optimizes away. > > Any disadvantage or objection to selectively use this form > in our kernel code for parts that need to work on multiple > platforms ? Better to just define a UNUSED_ARG() macro for this, that does the cast. This will save you having to go over every file again, should you ever encounter a compiler that complains about useless casts to void... Then again, whatever macro name we come up with, might also clash with Linux. I'm afraid there is no good portable solution, except possibly undefining __unused just before including Linux headers, then re-defining it, but that is rather ugly. Otherwise, either Linux renames all their __unused instances, or we rename all of them. Alternatively, we can introduce an __unused2 macro, just as ugly as the __dead2 and __pure2 macros. Then replace __unused with __unused2 in the files that you intend to port to Linux. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: (void)foo or __unused foo ?
Hi, On Fri, 27 Jul 2012 11:38:24 +0200 Luigi Rizzo wrote: > In writing cross platform code I often have to deal with function > arguments or variables that are not used on certain platforms. > In FreeBSD:sys/cdefs.h we have > if I understand you right here, it is you own code that has to run on different platforms. I can only tell what we are doing since a long long time. We have one file which handles all these things in one central location. This makes all other files independent of the platform but this one file might needs some work when a new platform comes in or things change on one platform. > Any disadvantage or objection to selectively use this form > in our kernel code for parts that need to work on multiple > platforms ? This concept also works inside a kernel, driver or in the world. The concept should then be limited to the module. Erich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
