Please note crosspost.
Often when writing code requiring function pointers, it is necessary
to write functions that ignore their formal parameters. For example,
a state machine function might take a status input, but a certain
error-handling state might ignore it:
typedef void (*State_Fn)(uin t8_t);
void error_state(uin t8_t status)
{
NOT_USED(status );
/* code handling error but ignoring status */
}
In another group, a poster asked about defining a macro NOT_USED as
shown above to quiet the compiler warning. His suggested
implementation was
#define NOT_USED(p) ((void)(p))
In this particular case, he noted the compiler he was using would
generate the warning even in the presence of this macro. I suggested
he use
#define NOT_USED(p) ((p)=(p))
He was pleased that it worked, but was concerned that the former
implementation was more widely supported, and that the latter might
generate executable code. I for one had never seen the former before,
though I've often seen the latter (usually not hidden behind a macro),
and I've never seen it actually generate code. At least, not in the
last ten years or so.
So I'm curious. Which form (if either) is more common? Are there any
implementations that will generate executable code for the latter?
Thanks,
-=Dave
-=Dave
--
Change is inevitable, progress is not.
Nov 15 '05
40 7905
Alexei A. Frounze wrote: "Thad Smith" <Th*******@acm. org> wrote in message news:43******** *************** @auth.newsreade r.octanews.com. .. ...
I have used a void cast for some compilers. For another, I was successful with
#define UNUSED(x) if(x);
Nice, though some clever compiler could warn here whether or not you're sure it's what you intend to do, whether or not this code has any effect.
Of course. The compiler in question (an old Keil compiler) gave a
warning for the void cast. I experimented and found that if(x);;
(another semicolon added after the macro invocation) generated no code
and no warning for that compiler. With no standard way to do this, we
are left to search about for implementation-dependent hacks.
Thad
Thad Smith <Th*******@acm. org> writes:
[suppressed "parameter not used" warnings] With no standard way to do this, we are left to search about for implementation-dependent hacks.
Personally, I use an implementation-dependent feature that works
for the compilers I really care about. Why worry about trying to
suppress warnings on every compiler? It's not possible and you
could waste a lot of time trying.
--
"Large amounts of money tend to quench any scruples I might be having."
-- Stephan Wilms
On 2005-10-05, Ben Pfaff <bl*@cs.stanfor d.edu> wrote: Thad Smith <Th*******@acm. org> writes:
[suppressed "parameter not used" warnings] With no standard way to do this, we are left to search about for implementation-dependent hacks.
Personally, I use an implementation-dependent feature that works for the compilers I really care about. Why worry about trying to suppress warnings on every compiler? It's not possible and you could waste a lot of time trying.
Here in comp.arch.embed ded, anybody with too strong an aversion
to implementation-dependent "hacks" is in for a lifetime of
frustration. There are just too many times when there simply
is no other way to accomplish that which must be accomplished.
Sure, standard and portable is always a good goal, but when
theres a 90+ percent chance the program is never going to be
compiled by a different compiler or run on a different
platform, there's a limit to how much utility should be
sacrificed and much effort should be expended to avoid usign
somethign like gcc's __attribute__(( )) extension.
--
Grant Edwards grante Yow! My LIBRARY CARD
at expired...
visi.com
Ben Pfaff wrote: Thad Smith <Th*******@acm. org> writes:
[suppressed "parameter not used" warnings] With no standard way to do this, we are left to search about for implementation-dependent hacks. Personally, I use an implementation-dependent feature that works for the compilers I really care about.
Same here.
Why worry about trying to suppress warnings on every compiler?
I don't know. I'm certainly not advocating such worry.
It's not possible and you could waste a lot of time trying.
True. I typically only work with a few compilers and spend a little
time to customize such things as eliminating unneeded warnings, which
allows me to more easily find real problems. Turning off warnings,
ignoring them, or sprinkling non-standard code throughout is a last
resort for me. You may have other techniques that work better for
you.
Thad
In article <1128616135.460 50bff8a89745339 c73052e1094284@ teranews>,
Thad Smith <Th*******@acm. org> wrote: Ben Pfaff wrote: Thad Smith <Th*******@acm. org> writes:
[suppressed "parameter not used" warnings] > With no standard way to do this, we are left to search about > for implementation-dependent hacks. Personally, I use an implementation-dependent feature that works for the compilers I really care about.
Same here.
Why worry about trying to suppress warnings on every compiler?
I don't know. I'm certainly not advocating such worry.
It's not possible and you could waste a lot of time trying.
True. I typically only work with a few compilers and spend a little time to customize such things as eliminating unneeded warnings, which allows me to more easily find real problems. Turning off warnings, ignoring them, or sprinkling non-standard code throughout is a last resort for me. You may have other techniques that work better for you.
Indeed there is a much better technique.
Make clean code. Catch the warnings in a file.
Carefully inspect the warnings and head them.
Catch the warnings on the resulting cleaner code.
Now in the regression test, expect the warnings to remain
the same, i.e. make a diff with the file with the warnings
of the previous test.
Only act on warnings changes, indicative of new warnings.
Or on warnings that went away since you cleaned up your code.
Never ever becludge your code to suppress warnings.
They are there to ... warn you, which is a Good Thing. Thad
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters. al****@spenarnc .xs4all.nl http://home.hccnet.nl/a.w.m.van.der.horst
Albert van der Horst <al****@spenarn c.xs4all.nl> wrote:
# Indeed there is a much better technique.
# Make clean code. Catch the warnings in a file.
Recompile megabytes of source code because you change one
function declaration in a header file.
--
SM Ryan http://www.rawbw.com/~wyrmwif/
Raining down sulphur is like an endurance trial, man. Genocide is the
most exhausting activity one can engage in. Next to soccer.
Albert van der Horst wrote: In article <1128616135.460 50bff8a89745339 c73052e1094284@ teranews>, Thad Smith <Th*******@acm. org> wrote:
True. I typically only work with a few compilers and spend a little time to customize such things as eliminating unneeded warnings, which allows me to more easily find real problems. Turning off warnings, ignoring them, or sprinkling non-standard code throughout is a last resort for me. You may have other techniques that work better for you.
Indeed there is a much better technique. Make clean code. Catch the warnings in a file. Carefully inspect the warnings and head them. Catch the warnings on the resulting cleaner code. Now in the regression test, expect the warnings to remain the same, i.e. make a diff with the file with the warnings of the previous test. Only act on warnings changes, indicative of new warnings.
That's an interesting idea! I suppose I should strip the line numbers
on the warnings so that code insertion/deletion doesn't trigger an
avalanche in the diff. It's time for a little scripting. I'll have
to give that a try. I could even fail a make if the warning file
changed.
Or on warnings that went away since you cleaned up your code.
Hmmm, the ominous disappearing warning!
Never ever becludge your code to suppress warnings.
The goal, of course, is to easily detect new warnings so that they can
be examined. Your approach is an interesting one.
They are there to ... warn you, which is a Good Thing.
Well, yes. That's why I try to hint to the compiler that its OK that
an if statement has a constant expression (because the macro it is in
takes various parameters).
Let's see, if I have conditional sections in my code, the warnings may
come and go as I change switches -- oh, dear! I suppose I should have
to have a separate expected warnings file for each configuration.
Thad
In comp.lang.c Thad Smith <Th*******@acm. org> wrote: Albert van der Horst wrote:
[snip] Make clean code. Catch the warnings in a file. Carefully inspect the warnings and head them. Catch the warnings on the resulting cleaner code. Now in the regression test, expect the warnings to remain the same, i.e. make a diff with the file with the warnings of the previous test. Only act on warnings changes, indicative of new warnings.
That's an interesting idea! I suppose I should strip the line numbers on the warnings so that code insertion/deletion doesn't trigger an avalanche in the diff. It's time for a little scripting. I'll have to give that a try. I could even fail a make if the warning file changed.
This idea has been wandering around me for some time, too.
It could work like this: programmer puts #pramas in the code,
which contain verbatim quotes (or regexes, or identifires) of warnings
that are to be suppressed for the next line. The utility program (or
a script) calculates line numbers and produces a list of warnings
(with the line numbers) to cut out from the compiler output.
Like this:
#pragma nowarn t.c:%n: warning: comparison between signed and unsigned
if (u>s)
--
Stan Tobias
mailx `echo si***@FamOuS.Be dBuG.pAlS.INVALID | sed s/[[:upper:]]//g`
S.Tobias wrote On 10/13/05 17:19,: In comp.lang.c Thad Smith <Th*******@acm. org> wrote:
Albert van der Horst wrote:
[snip]
Make clean code. Catch the warnings in a file. Carefully inspect the warnings and head them. Catch the warnings on the resulting cleaner code. Now in the regression test, expect the warnings to remain the same, i.e. make a diff with the file with the warnings of the previous test. Only act on warnings changes, indicative of new warnings.
That's an interesting idea! I suppose I should strip the line numbers on the warnings so that code insertion/deletion doesn't trigger an avalanche in the diff. It's time for a little scripting. I'll have to give that a try. I could even fail a make if the warning file changed.
This idea has been wandering around me for some time, too. It could work like this: programmer puts #pramas in the code, which contain verbatim quotes (or regexes, or identifires) of warnings that are to be suppressed for the next line. The utility program (or a script) calculates line numbers and produces a list of warnings (with the line numbers) to cut out from the compiler output. Like this: #pragma nowarn t.c:%n: warning: comparison between signed and unsigned if (u>s)
Ugh. Ugh ugh ugh.
First, while the use of warning-suppressing tags in the
code goes back at least to lint, using #pragma to express
them is a truly terrible idea. Somewhere there'll be a
compiler that actually recognizes "#pragma nowarn" and does
something with it -- for example, suppressing all warning
messages for the entire translation unit, or turning on
ARN (automatic name rewriting) NOW. Embed such tags in
specially-formatted comments that are linquistically inert,
not in constructs that might at any moment turn into toxic
chemicals and rot your program.
(Aside: I quite understand that the idea of "a different
compiler" may well be foreign to many projects of interest
in comp.arch.embed ded. However, the thread is cross-posted
to comp.lang.c as well, where portability concerns appear to
carry somewhat more weight.)
Second, a far better way to suppress the warning you
mention is
if (u > (unsigned)s)
Sometimes it can be a bad thing for a "last resort" mechanism
to exist: it's too easy for people to give up searching for
the "first resort."
Finally, and it's been said before: The goal of turning
of ALL warnings from ALL compilers is ultimately futile,
because compilers are allowed to complain about anything
they feel like. "Warning: Source was modified at 2:37 AM;
sleep-deprived programmer may have made more mistakes than
usaul."
-- Er*********@sun .com
In comp.lang.c Eric Sosman <er*********@su n.com> wrote: S.Tobias wrote On 10/13/05 17:19,: In comp.lang.c Thad Smith <Th*******@acm. org> wrote:Albert van der Horst wrote: [snip]Make clean code. Catch the warnings in a file. Carefully inspect the warnings and head them. Catch the warnings on the resulting cleaner code. Now in the regression test, expect the warnings to remain the same, i.e. make a diff with the file with the warnings of the previous test. Only act on warnings changes, indicative of new warnings. That's an interesting idea! I suppose I should strip the line numbers on the warnings so that code insertion/deletion doesn't trigger an avalanche in the diff. It's time for a little scripting. I'll have to give that a try. I could even fail a make if the warning file changed. This idea has been wandering around me for some time, too. It could work like this: programmer puts #pramas in the code, which contain verbatim quotes (or regexes, or identifires) of warnings that are to be suppressed for the next line. The utility program (or a script) calculates line numbers and produces a list of warnings (with the line numbers) to cut out from the compiler output. Like this: #pragma nowarn t.c:%n: warning: comparison between signed and unsigned if (u>s)
Ugh. Ugh ugh ugh.
That's how great ideas die - someone says "ugh"... ;-)
First, while the use of warning-suppressing tags in the code goes back at least to lint, using #pragma to express them is a truly terrible idea. Somewhere there'll be a compiler that actually recognizes "#pragma nowarn" and does something with it -- for example, suppressing all warning messages for the entire translation unit, or turning on ARN (automatic name rewriting) NOW.
:-)Embed such tags in specially-formatted comments that are linquistically inert, not in constructs that might at any moment turn into toxic chemicals and rot your program.
That's true. All #pragmas (with a small exception) suffer from this
disease. OTOH the whole concept is subject to implementation behaviour
and is not (universally) portable. But I agree, it's always better to
avoid a mine-field, and take a quiet and safe path.
(Only, what if the compiler uses the same tags embedded in comments
for its own purposes, too?)
What might actually be bad in practice with #pragmas is that a
compiler might issue warnings about unrecognized #pragmas, thus
we'd be chasing our tail.
Let's make that:
/* $ nowarn: ... $ */
(Actually, only `$ nowarn: ... $' part is recognized by the utility.)
Second, a far better way to suppress the warning you mention is
if (u > (unsigned)s)
Sometimes it can be a bad thing for a "last resort" mechanism to exist: it's too easy for people to give up searching for the "first resort."
That was just a poor example how it could be used. Anyway,
you had to clutter the code to suppress the warning, too.
Sometimes there's no way of "fixing" warnings for all compilers,
you do it for one, and some other issue arises for another.
Consider this (semi-real-life example):
off_t off;
size_t siz;
if (siz > off) ;
may cause:
warning: signed/unsigned in comparison
on one implementation, whereas
if (siz > (size_t)off) ;
on another may issue:
warning: possible loss of data in cast
(besides that casting always makes me feel uneasy).
It's not obvious which side to cast to which.
(I actually solved it this way (through a macro):
if(siz + (off_t)0 > off + (size_t)0) ;
(clue: usual arithmetic conversions).
)
Finally, and it's been said before: The goal of turning of ALL warnings from ALL compilers is ultimately futile, because compilers are allowed to complain about anything they feel like. "Warning: Source was modified at 2:37 AM; sleep-deprived programmer may have made more mistakes than usaul."
Well, yes, but my goal is not to turn off ALL warnings, but
only *known* and *inspected* warnings. The idea is that
I don't waste my work when line numbers change.
--
Stan Tobias
mailx `echo si***@FamOuS.Be dBuG.pAlS.INVALID | sed s/[[:upper:]]//g` This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics |
by: harry |
last post by:
Hi,
During compilation, a C# project in my solution triggers the following
warning:
"warning CS0168: The variable 'ex' is declared but never used"
To trigger this warning, it appears the C# compiler WarningLevel needs to be
3 or above.
|
by: Charles Sullivan |
last post by:
I have a number of functions, e.g.:
int funct1( int arg1, int arg2, int arg3 );
int funct2( int arg1, int arg2, int arg3 );
int funct3( int arg1, int arg2, int arg3 );
that are called via pointers in a table, with the
same parameters regardless of the particular
function.
In some of the functions, one or more of the
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it.
First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it.
Here is my compilation command:
g++-12 -std=c++20 -Wnarrowing bit_field.cpp
Here is the code in...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
| |
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one.
At the time of converting from word file to html my equations which are in the word document file was convert into image.
Globals.ThisAddIn.Application.ActiveDocument.Select();...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols.
I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
|
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...
| |