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

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

Multi-instructions macro and compiler warning

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

Contents

  Multi-instructions macro and compiler warning pozz <pozzugno@gmail.com> - 2011-10-16 09:09 +0200
    Re: Multi-instructions macro and compiler warning Ian Collins <ian-news@hotmail.com> - 2011-10-16 20:31 +1300
      Re: Multi-instructions macro and compiler warning pozz <pozzugno@gmail.com> - 2011-10-16 09:41 +0200
        Re: Multi-instructions macro and compiler warning Ian Collins <ian-news@hotmail.com> - 2011-10-16 20:49 +1300
          Re: Multi-instructions macro and compiler warning pozz <pozzugno@gmail.com> - 2011-10-16 10:16 +0200
            Re: Multi-instructions macro and compiler warning Ian Collins <ian-news@hotmail.com> - 2011-10-16 23:09 +1300
              Re: Multi-instructions macro and compiler warning pozz <pozzugno@gmail.com> - 2011-10-17 02:37 -0700
                Re: Multi-instructions macro and compiler warning Ian Collins <ian-news@hotmail.com> - 2011-10-17 23:04 +1300
                Re: Multi-instructions macro and compiler warning Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-10-17 11:06 +0100
                  Re: Multi-instructions macro and compiler warning pozz <pozzugno@gmail.com> - 2011-10-17 03:23 -0700
                Re: Multi-instructions macro and compiler warning Keith Thompson <kst-u@mib.org> - 2011-10-17 12:30 -0700
        Re: Multi-instructions macro and compiler warning "BartC" <bc@freeuk.com> - 2011-10-16 12:47 +0100
          Re: Multi-instructions macro and compiler warning Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-10-16 22:16 +0000
          Re: Multi-instructions macro and compiler warning pozz <pozzugno@gmail.com> - 2011-10-17 02:42 -0700
            Re: Multi-instructions macro and compiler warning "BartC" <bc@freeuk.com> - 2011-10-17 13:10 +0100
        Re: Multi-instructions macro and compiler warning bert <bert.hutchings@btinternet.com> - 2011-10-16 05:33 -0700
    Re: Multi-instructions macro and compiler warning Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-10-16 09:02 -0400
    Re: Multi-instructions macro and compiler warning "christian.bau" <christian.bau@cbau.wanadoo.co.uk> - 2011-10-16 07:40 -0700
      Re: Multi-instructions macro and compiler warning ImpalerCore <jadill33@gmail.com> - 2011-10-17 08:07 -0700
        Re: Multi-instructions macro and compiler warning "christian.bau" <christian.bau@cbau.wanadoo.co.uk> - 2011-10-17 09:25 -0700
          Re: Multi-instructions macro and compiler warning James Kuyper <jameskuyper@verizon.net> - 2011-10-17 12:58 -0400
            Re: Multi-instructions macro and compiler warning Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-10-18 07:43 -0400
              Re: Multi-instructions macro and compiler warning Keith Thompson <kst-u@mib.org> - 2011-10-18 11:52 -0700
          Re: Multi-instructions macro and compiler warning ImpalerCore <jadill33@gmail.com> - 2011-10-17 10:41 -0700
    Re: Multi-instructions macro and compiler warning Jean-Christophe <5.d@free.fr> - 2011-10-16 10:02 -0700
      Re: Multi-instructions macro and compiler warning Kleuskes & Moos <kleuske@somewhere.else.net> - 2011-10-16 17:44 +0000
      Re: Multi-instructions macro and compiler warning Keith Thompson <kst-u@mib.org> - 2011-10-16 13:49 -0700
        Re: Multi-instructions macro and compiler warning Ian Collins <ian-news@hotmail.com> - 2011-10-17 10:00 +1300
    Re: Multi-instructions macro and compiler warning Kenneth Brody <kenbrody@spamcop.net> - 2011-10-17 12:50 -0400
      Re: Multi-instructions macro and compiler warning "Morris Keesan" <mkeesan@post.harvard.edu> - 2011-10-17 14:50 -0400

Page 1 of 2  [1] 2  Next page →

#11754 — Multi-instructions macro and compiler warning

I'm trying to increase the warning level during compilation.  My goal is 
to reach the maximum warning level without any warning message after 
compilation.  I think this is a Good Thing to do when programming.

After changing warning level from 4 to 5, I received many warning 
messages of the type

   W1207C: conditional expression is constant: dowhile

Those messages refer to multi-instructions macros defined as below:

   #define MACRO(a, b)  do { foo(a); bar(b); } while(0)

Many times I read to use the trick do/while(0) to write 
multi-instruction macros to avoid other problems during compilation.  In 
this way, I can use MACRO() at any point where I could use a normal 
function.

How can I avoid the warning message W1207C?  I'm using an embedded 
microcontroller C compiler from Fujitsu, named Softune.

[toc] | [next] | [standalone]

#11755

On 10/16/11 08:09 PM, pozz wrote:
> I'm trying to increase the warning level during compilation.  My goal is
> to reach the maximum warning level without any warning message after
> compilation.  I think this is a Good Thing to do when programming.
>
> After changing warning level from 4 to 5, I received many warning
> messages of the type
>
>     W1207C: conditional expression is constant: dowhile
>
> Those messages refer to multi-instructions macros defined as below:
>
>     #define MACRO(a, b)  do { foo(a); bar(b); } while(0)
>
> Many times I read to use the trick do/while(0) to write
> multi-instruction macros to avoid other problems during compilation.  In
> this way, I can use MACRO() at any point where I could use a normal
> function.
>
> How can I avoid the warning message W1207C?  I'm using an embedded
> microcontroller C compiler from Fujitsu, named Softune.

Use a function.  Any decent compiler will inline something that trivial.

-- 
Ian Collins

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

#11756

Il 16/10/2011 09:31, Ian Collins ha scritto:
> On 10/16/11 08:09 PM, pozz wrote:
>> I'm trying to increase the warning level during compilation. My goal is
>> to reach the maximum warning level without any warning message after
>> compilation. I think this is a Good Thing to do when programming.
>>
>> After changing warning level from 4 to 5, I received many warning
>> messages of the type
>>
>> W1207C: conditional expression is constant: dowhile
>>
>> Those messages refer to multi-instructions macros defined as below:
>>
>> #define MACRO(a, b) do { foo(a); bar(b); } while(0)
>>
>> Many times I read to use the trick do/while(0) to write
>> multi-instruction macros to avoid other problems during compilation. In
>> this way, I can use MACRO() at any point where I could use a normal
>> function.
>>
>> How can I avoid the warning message W1207C? I'm using an embedded
>> microcontroller C compiler from Fujitsu, named Softune.
>
> Use a function. Any decent compiler will inline something that trivial.

I have *many* macros of the same type (do/while(0)) in my projects, 
sparsed over source and include files.  The trivial MACRO() macro in my 
original post is just an example to describe my approach for 
multi-instructions macros.

Should I change a macro for a function just to avoid a warning from 
compiler?  It doesn't make sense to me.

And another curiosity.  Is a C compiler optimizer able to convert a 
function call to inline even if the function implementation (its code) 
is in a different C module file?

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

#11758

On 10/16/11 08:41 PM, pozz wrote:
> Il 16/10/2011 09:31, Ian Collins ha scritto:
>> On 10/16/11 08:09 PM, pozz wrote:
>>> I'm trying to increase the warning level during compilation. My goal is
>>> to reach the maximum warning level without any warning message after
>>> compilation. I think this is a Good Thing to do when programming.
>>>
>>> After changing warning level from 4 to 5, I received many warning
>>> messages of the type
>>>
>>> W1207C: conditional expression is constant: dowhile
>>>
>>> Those messages refer to multi-instructions macros defined as below:
>>>
>>> #define MACRO(a, b) do { foo(a); bar(b); } while(0)
>>>
>>> Many times I read to use the trick do/while(0) to write
>>> multi-instruction macros to avoid other problems during compilation. In
>>> this way, I can use MACRO() at any point where I could use a normal
>>> function.
>>>
>>> How can I avoid the warning message W1207C? I'm using an embedded
>>> microcontroller C compiler from Fujitsu, named Softune.
>>
>> Use a function. Any decent compiler will inline something that trivial.
>
> I have *many* macros of the same type (do/while(0)) in my projects,
> sparsed over source and include files.  The trivial MACRO() macro in my
> original post is just an example to describe my approach for
> multi-instructions macros.
>
> Should I change a macro for a function just to avoid a warning from
> compiler?  It doesn't make sense to me.

But changing them because function like macros are an anachronism (or an 
abomination, depending on your point of view) does make sense.

> And another curiosity.  Is a C compiler optimizer able to convert a
> function call to inline even if the function implementation (its code)
> is in a different C module file?

The compiler can't, but some linkers can.

-- 
Ian Collins

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

#11759

Il 16/10/2011 09:49, Ian Collins ha scritto:
> On 10/16/11 08:41 PM, pozz wrote:
>> And another curiosity. Is a C compiler optimizer able to convert a
>> function call to inline even if the function implementation (its code)
>> is in a different C module file?
>
> The compiler can't, but some linkers can.

I tried, the linker I'm using can't.  Also the compiler (even with 
optimization) doesn't transform normal functions to inline functions, 
without the inline keyword.

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

#11760

On 10/16/11 09:16 PM, pozz wrote:
> Il 16/10/2011 09:49, Ian Collins ha scritto:
>> On 10/16/11 08:41 PM, pozz wrote:
>>> And another curiosity. Is a C compiler optimizer able to convert a
>>> function call to inline even if the function implementation (its code)
>>> is in a different C module file?
>>
>> The compiler can't, but some linkers can.
>
> I tried, the linker I'm using can't.  Also the compiler (even with
> optimization) doesn't transform normal functions to inline functions,
> without the inline keyword.


So use it!  At least the compiler honours the hint.  Embedded compilers 
tend to offer more control over what is and isn't inlined than their 
hosted brethren.

-- 
Ian Collins

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

#11798

On 16 Ott, 12:09, Ian Collins <ian-n...@hotmail.com> wrote:
> On 10/16/11 09:16 PM, pozz wrote:
> > I tried, the linker I'm using can't.  Also the compiler (even with
> > optimization) doesn't transform normal functions to inline functions,
> > without the inline keyword.
>
> So use it!  At least the compiler honours the hint.  Embedded compilers
> tend to offer more control over what is and isn't inlined than their
> hosted brethren.

Unfortunately, I have another "warning" problem if I use inline
functions.

Suppose I have a macro that activate a relay connected to a
microcontroller pin:

  #define RELAY_ON()  do {PIN_SET_OUTPUT(10); PIN_SET(PIN(10));}
while(0)

The first instruction is to configure the pin as an output; the second
is to set its level to high.

Transforming this macro to an inline function, I would write:

  #pragma inline relay_on
  void relay_on(void) {
    PIN_SET_OUTPUT(10);
    PIN_SET(PIN(10));
  }

If this function is accessible just from one compilation module, it is
simple to use it:

-- test.c --
#include "cpu.h"

#pragma inline relay_on
static void relay_on(void) {
  PIN_SET_OUTPUT(10);
  PIN_SET(PIN(10));
}

void test(void) {
  relay_on();
  /* other things */
}
-- test.h --
#ifndef TEST_H
#define TEST_H
#include "test.h"
void test(void);
#endif
--

The compilation ends without any errors and warnings.

The problem happens when I try to use this function in more than one
module,
so moving the code to include file (I think this is the way to have an
extern
inline function):

-- test.h --
#ifndef TEST_H
#define TEST_H

#pragma inline relay_on
void relay_on(void) {
  PIN_SET_OUTPUT(10);
  PIN_SET(PIN(10));
}

#endif
--

If I include test.h in more than one file, the compilation ends with
the warning

  W1327L: Duplicate symbol definition (_relay_on)

even if the function relay_on() is never used. So the use of inline
function to
avoid a warning has produced another warning :-(

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

#11799

On 10/17/11 10:37 PM, pozz wrote:
> On 16 Ott, 12:09, Ian Collins<ian-n...@hotmail.com>  wrote:
>> On 10/16/11 09:16 PM, pozz wrote:
>>> I tried, the linker I'm using can't.  Also the compiler (even with
>>> optimization) doesn't transform normal functions to inline functions,
>>> without the inline keyword.
>>
>> So use it!  At least the compiler honours the hint.  Embedded compilers
>> tend to offer more control over what is and isn't inlined than their
>> hosted brethren.
>
> Unfortunately, I have another "warning" problem if I use inline
> functions.
>
> Suppose I have a macro that activate a relay connected to a
> microcontroller pin:
>
>    #define RELAY_ON()  do {PIN_SET_OUTPUT(10); PIN_SET(PIN(10));}
> while(0)
>
> The first instruction is to configure the pin as an output; the second
> is to set its level to high.
>
> Transforming this macro to an inline function, I would write:
>
>    #pragma inline relay_on
>    void relay_on(void) {
>      PIN_SET_OUTPUT(10);
>      PIN_SET(PIN(10));
>    }
>
> If this function is accessible just from one compilation module, it is
> simple to use it:
>
> -- test.c --
> #include "cpu.h"
>
> #pragma inline relay_on
> static void relay_on(void) {
>    PIN_SET_OUTPUT(10);
>    PIN_SET(PIN(10));
> }
>
> void test(void) {
>    relay_on();
>    /* other things */
> }
> -- test.h --
> #ifndef TEST_H
> #define TEST_H
> #include "test.h"
> void test(void);
> #endif
> --
>
> The compilation ends without any errors and warnings.
>
> The problem happens when I try to use this function in more than one
> module,
> so moving the code to include file (I think this is the way to have an
> extern
> inline function):
>
> -- test.h --
> #ifndef TEST_H
> #define TEST_H
>
> #pragma inline relay_on
> void relay_on(void) {
>    PIN_SET_OUTPUT(10);
>    PIN_SET(PIN(10));
> }
>
> #endif
> --
>
> If I include test.h in more than one file, the compilation ends with
> the warning
>
>    W1327L: Duplicate symbol definition (_relay_on)
>
> even if the function relay_on() is never used. So the use of inline
> function to
> avoid a warning has produced another warning :-(
>
Well your "#pragma inline" doesn't follow the rules for inline 
functions.  if the compiler did,

inline void relay_on(void) {}

would avoid multiple inclusion.

Try "static void " rather than "inline void", it should have the same 
effect.

-- 
Ian Collins

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

#11800

pozz <pozzugno@gmail.com> writes:
<snip>
> Unfortunately, I have another "warning" problem if I use inline
> functions.
<snip>
> Transforming this macro to an inline function, I would write:
>
>   #pragma inline relay_on
>   void relay_on(void) {
>     PIN_SET_OUTPUT(10);
>     PIN_SET(PIN(10));
>   }
>
> If this function is accessible just from one compilation module, it is
> simple to use it:
<snip>
> The problem happens when I try to use this function in more than one
> module,
> so moving the code to include file (I think this is the way to have an
> extern
> inline function):
>
> -- test.h --
> #ifndef TEST_H
> #define TEST_H
>
> #pragma inline relay_on
> void relay_on(void) {
>   PIN_SET_OUTPUT(10);
>   PIN_SET(PIN(10));
> }
>
> #endif
> --
>
> If I include test.h in more than one file, the compilation ends with
> the warning
>
>   W1327L: Duplicate symbol definition (_relay_on)
>
> even if the function relay_on() is never used. So the use of inline
> function to
> avoid a warning has produced another warning :-(

Make the function static.

-- 
Ben.

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

#11804

On 17 Ott, 12:06, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> pozz <pozzu...@gmail.com> writes:
>
> <snip>
>
>
>
>
>
>
>
>
>
> > Unfortunately, I have another "warning" problem if I use inline
> > functions.
> <snip>
> > Transforming this macro to an inline function, I would write:
>
> >   #pragma inline relay_on
> >   void relay_on(void) {
> >     PIN_SET_OUTPUT(10);
> >     PIN_SET(PIN(10));
> >   }
>
> > If this function is accessible just from one compilation module, it is
> > simple to use it:
> <snip>
> > The problem happens when I try to use this function in more than one
> > module,
> > so moving the code to include file (I think this is the way to have an
> > extern
> > inline function):
>
> > -- test.h --
> > #ifndef TEST_H
> > #define TEST_H
>
> > #pragma inline relay_on
> > void relay_on(void) {
> >   PIN_SET_OUTPUT(10);
> >   PIN_SET(PIN(10));
> > }
>
> > #endif
> > --
>
> > If I include test.h in more than one file, the compilation ends with
> > the warning
>
> >   W1327L: Duplicate symbol definition (_relay_on)
>
> > even if the function relay_on() is never used. So the use of inline
> > function to
> > avoid a warning has produced another warning :-(
>
> Make the function static.

See my answer to BartC below. If I declare the inline function static,
I receive
a warning when I include the file without using the function... :-(

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

#11834

pozz <pozzugno@gmail.com> writes:
[...]
> Suppose I have a macro that activate a relay connected to a
> microcontroller pin:
>
>   #define RELAY_ON()  do {PIN_SET_OUTPUT(10); PIN_SET(PIN(10));}
> while(0)
[...]

Are PIN_SET_OUTPUT and PIN_SET functions or macros?

If they're functions, or if they're macros whose invocations expand to
valid expressions, then you can just do this:

    #define RELAY_ON() ( PIN_SET_OUTPUT(10), PIN_SET(PIN(10)) )

There's no need for the "do { ... } while (0)" trick unless you
need to use control-flow constructs (if, for, while) -- and "if"
can often be replaced with "?:".  Just about anything that doesn't
require looping can be made into an expression.

This assumes you really need to make it a macro.  If you're able
to make it a function (inline or not), then of course you can use
any control-flow you like.

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

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

#11761

"pozz" <pozzugno@gmail.com> wrote in message
news:j7e1qm$7te$1@nnrp.ngi.it...
> Il 16/10/2011 09:31, Ian Collins ha scritto:

>> Use a function. Any decent compiler will inline something that trivial.

> And another curiosity.  Is a C compiler optimizer able to convert a
> function call to inline even if the function implementation (its code) is
> in a different C module file?

The body of a macro has to be visible to the program. The same can be done
with functions.

But sharing the same function across several modules means putting the
function definition in an include file, which is usually not done.

The code will be duplicated in each module, but that will happen many times
anyway if you want the function to be inlined.

You also need to put 'static' in front of the function definition to keep 
the name of each one local, otherwise they will all clash with each other.

-- 
Bartc
 

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

#11786

On Sun, 2011-10-16, BartC wrote:
...
> The body of a macro has to be visible to the program. The same can be done
> with functions.
>
> But sharing the same function across several modules means putting the
> function definition in an include file, which is usually not done.

Maybe it's usually not done, but it *should* be (if you have a modern
compiler).  Things which don't *have* to be macros should be inline
functions, for readability and type safety.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#11801

On 16 Ott, 13:47, "BartC" <b...@freeuk.com> wrote:
> The body of a macro has to be visible to the program. The same can be done
> with functions.
>
> But sharing the same function across several modules means putting the
> function definition in an include file, which is usually not done.

So isn't it possible to share an inline function among several
modules?


> The code will be duplicated in each module, but that will happen many times
> anyway if you want the function to be inlined.
>
> You also need to put 'static' in front of the function definition to keep
> the name of each one local, otherwise they will all clash with each other.

I tried with:

-- test.h --
#ifndef TEST_H
#define TEST_H

#pragma inline relay_on
static void relay_on(void) {
  PIN_SET_OUTPUT(10);
  PIN_SET(PIN(10));
}

#endif
--

but now I receive a warning message from the compiler if one module
includes
test.h without using relay_on() function (and this could be possible,
because
I usually have other definitions in the include file):

  W1204C: static symbol `relay_on' unused

It's a nightmare...

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

#11807

"pozz" <pozzugno@gmail.com> wrote in message 
news:8a974a79-9ee2-4f6f-8aa6-795b80b03080@x20g2000vbl.googlegroups.com...
> On 16 Ott, 13:47, "BartC" <b...@freeuk.com> wrote:

>> The code will be duplicated in each module, but that will happen many 
>> times
>> anyway if you want the function to be inlined.

> -- test.h --
> #ifndef TEST_H
> #define TEST_H
>
> #pragma inline relay_on
> static void relay_on(void) {
>  PIN_SET_OUTPUT(10);
>  PIN_SET(PIN(10));
> }
>
> #endif
> --
>
> but now I receive a warning message from the compiler if one module
> includes
> test.h without using relay_on() function (and this could be possible,
> because
> I usually have other definitions in the include file):
>
>  W1204C: static symbol `relay_on' unused
>
> It's a nightmare...

No, it's just a warning, not an error.

You can ignore the warning. Or find some compiler switch that turns the 
warning off.

Or create a more complex include file scheme, so that these functions are 
declared in their own header, and included only when used. Or use a dummy 
function that makes use of 'relay_on' (that's assuming that doesn't generate 
yet another warning about not calling the dummy function...)

-- 
Bartc 

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

#11763

On Sunday, October 16, 2011 8:41:10 AM UTC+1, pozz wrote:
> Il 16/10/2011 09:31, Ian Collins ha scritto:
> > On 10/16/11 08:09 PM, pozz wrote:
> >> I'm trying to increase the warning level during compilation. My goal is
> >> to reach the maximum warning level without any warning message after
> >> compilation. I think this is a Good Thing to do when programming.
> >>
> >> After changing warning level from 4 to 5, I received many warning
> >> messages of the type
> >>
> >> W1207C: conditional expression is constant: dowhile
> >>
> >> Those messages refer to multi-instructions macros defined as below:
> >>
> >> #define MACRO(a, b) do { foo(a); bar(b); } while(0)
> >>
> >> Many times I read to use the trick do/while(0) to write
> >> multi-instruction macros to avoid other problems during compilation. In
> >> this way, I can use MACRO() at any point where I could use a normal
> >> function.
> >>
> >> How can I avoid the warning message W1207C? I'm using an embedded
> >> microcontroller C compiler from Fujitsu, named Softune.
> >
> > Use a function. Any decent compiler will inline something that trivial.
> 
> I have *many* macros of the same type (do/while(0)) in my projects, 
> sparsed over source and include files.  The trivial MACRO() macro in my 
> original post is just an example to describe my approach for 
> multi-instructions macros.
> 
> Should I change a macro for a function just to avoid a warning from 
> compiler?  It doesn't make sense to me.

I think he meant an in-lineable function 
something like:

int never(void)
{   return 0;
}

then use while(never()); instead of while(0);
-- 

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

#11766

On 10/16/2011 3:09 AM, pozz wrote:
> I'm trying to increase the warning level during compilation. My goal is
> to reach the maximum warning level without any warning message after
> compilation. I think this is a Good Thing to do when programming.

     It's a worthwhile goal to strive for, but not one you should
expect to achieve every time.

> After changing warning level from 4 to 5, I received many warning
> messages of the type
>
> W1207C: conditional expression is constant: dowhile
>
> Those messages refer to multi-instructions macros defined as below:
>
> #define MACRO(a, b) do { foo(a); bar(b); } while(0)

     For this particular case, you could try

	#define MACRO(a,b) ( (void)foo(a) , (void)bar(b) )

... but this won't work if the expansion involves `for' or `return'
or other things that aren't expressions.

> Many times I read to use the trick do/while(0) to write
> multi-instruction macros to avoid other problems during compilation. In
> this way, I can use MACRO() at any point where I could use a normal
> function.

     No, you can't.  Try `return MACRO(x,y)', for example.

> How can I avoid the warning message W1207C? I'm using an embedded
> microcontroller C compiler from Fujitsu, named Softune.

     An implementation must emit diagnostics when mandated by the
Standard, but is allowed to emit whatever additional diagnostics
it likes.  For example, some compilers issue diagnostic messages
for `if (x = y)', a perfectly valid C construct but possibly a
typo for `if (x == y)'.  Compiler writers invent these things in
an attempt to draw your attention to "suspicious" constructs, and
different compiler writers have different notions of "suspicious."

     ... which is why you cannot expect to get to "Zero warnings"
with every piece of code.  Some compiler, somewhere, will find
something "suspicious" to warn about.  You may be able to come
up with a work-around that will silence the particular compiler in
question (consult the compiler's documentation, or ask in a group
where this particular embedded toolchain is familiar).  Then again,
it may happen that no such work-around exists.  And it's highly
unlikely that you'll find a work-around that will pass muster with
every compiler everywhere.

... but this approach will fail if the expansion involves `for'
or `return' or other non-expressions.

     So, seek to minimize warnings -- but don't expect to eliminate
them entirely.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#11770

On Oct 16, 8:09 am, pozz <pozzu...@gmail.com> wrote:

> How can I avoid the warning message W1207C?  I'm using an embedded
> microcontroller C compiler from Fujitsu, named Softune.

Many compilers give good warnings, but also rubbish warnings. You
certainly want your code to be free of warnings with the compiler
settings that you use, so that you notice whenever a new warning pops
up. But as you noticed yourself, being free of warnings with all
warnings in the compiler turned on is not a worthwhile goal.

"do { ... } while (0)", especially as the body of a macro, is such a
common idiom that getting a warning for it is wrong, and changing the
code to avoid the warning is wrong as well. Change the compiler
settings to avoid this warning, possibly complain to the compiler
maker.

(One of my negative favorites is warnings for initialising a struct as
"struct soandso x = { 0 };" which is a common idiom for initialising
all members to zero. Another is a warning for "if (x >= 0 && x <=
100)" if the type of x happens to be unsigned. )

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

#11812

On Oct 16, 10:40 am, "christian.bau"
<christian....@cbau.wanadoo.co.uk> wrote:
> On Oct 16, 8:09 am, pozz <pozzu...@gmail.com> wrote:
>
> > How can I avoid the warning message W1207C?  I'm using an embedded
> > microcontroller C compiler from Fujitsu, named Softune.
>
> Many compilers give good warnings, but also rubbish warnings. You
> certainly want your code to be free of warnings with the compiler
> settings that you use, so that you notice whenever a new warning pops
> up. But as you noticed yourself, being free of warnings with all
> warnings in the compiler turned on is not a worthwhile goal.
>
> "do { ... } while (0)", especially as the body of a macro, is such a
> common idiom that getting a warning for it is wrong, and changing the
> code to avoid the warning is wrong as well. Change the compiler
> settings to avoid this warning, possibly complain to the compiler
> maker.
>
> (One of my negative favorites is warnings for initialising a struct as
> "struct soandso x = { 0 };" which is a common idiom for initialising
> all members to zero. Another is a warning for "if (x >= 0 && x <=
> 100)" if the type of x happens to be unsigned. )

If 'x' is unsigned, I would think that one could use 'if (/*x >= 0
&&*/ x <= 100)' to document the condition while removing the warning,
as the 'x >= 0' condition is implicit from the use of an unsigned
type.

Best regards,
John D.

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

#11814

On Oct 17, 4:07 pm, ImpalerCore <jadil...@gmail.com> wrote:
> On Oct 16, 10:40 am, "christian.bau"
>
>
>
>
>
>
>
>
>
> <christian....@cbau.wanadoo.co.uk> wrote:
> > On Oct 16, 8:09 am, pozz <pozzu...@gmail.com> wrote:
>
> > > How can I avoid the warning message W1207C?  I'm using an embedded
> > > microcontroller C compiler from Fujitsu, named Softune.
>
> > Many compilers give good warnings, but also rubbish warnings. You
> > certainly want your code to be free of warnings with the compiler
> > settings that you use, so that you notice whenever a new warning pops
> > up. But as you noticed yourself, being free of warnings with all
> > warnings in the compiler turned on is not a worthwhile goal.
>
> > "do { ... } while (0)", especially as the body of a macro, is such a
> > common idiom that getting a warning for it is wrong, and changing the
> > code to avoid the warning is wrong as well. Change the compiler
> > settings to avoid this warning, possibly complain to the compiler
> > maker.
>
> > (One of my negative favorites is warnings for initialising a struct as
> > "struct soandso x = { 0 };" which is a common idiom for initialising
> > all members to zero. Another is a warning for "if (x >= 0 && x <=
> > 100)" if the type of x happens to be unsigned. )
>
> If 'x' is unsigned, I would think that one could use 'if (/*x >= 0
> &&*/ x <= 100)' to document the condition while removing the warning,
> as the 'x >= 0' condition is implicit from the use of an unsigned
> type.

Well, there are cases where a value x should be between some lower and
upper limit, and I would want to check for this condition without
having to write different code when the lower and upper limit have
some specific value. So I might have defined somewhere

enum { lowerlimit = 0 } or enum { lowerlimit = 1 }

and I should be allowed to write if (x >= lowerlimit && x <=
upperlimit) ... no matter what the particular value of lowerlimit is.
A method that works but is just daft is writing if ((x > lowerlimit ||
x == lowerlimit) && x <= upperlimit) ...

The point is that the warning in this case is completely pointless.
Same as the OP's warning for a do ... while (0) construct is
completely pointless. And the OP is looking at ways to write far
inferior code to remove warnings. In other words, warnings that should
help improving the code make it actually worse.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web