GCC warnings for comma operator

Discussion in 'C Programming' started by W Karas, Apr 11, 2013.

  1. W Karas

    W Karas Guest

    Recently I wrote a macro to set a bit field at an arbitrary location in an array of some unsigned integral type. (Can't show it because it's proprietary.) The bit field is specified as a bit offset from the start of the array, and the number of bits of width. Probably a mistake, but I decided it would (somehow) be more aesthetic if the macro expanded to an expression with side effects (and useless value) rather than a (compound) statement. The expanded macro has multiple instances of this pattern:

    yada-yada , (exprA ? exprB : 0), yada-yada

    where exprB has side effects. GCC seems to have no complaints as long as exprB evaluates to a constant value known at compile time. But if exprB hasa variable in it, and exprA is false, GCC gives a "value not used in commaexpression" warning (using -Wall) or something like that. The -Wno-unused-value option eliminates this warning. I would like to ask 2 questions.

    1) What are some problems I might miss by using -Wno-unused-value ? I thought it might disable the warning for unused variables, but that is separate and covered by -Wunused-variables.

    2) Is there a more targeted way to eliminate this spurious warning? I'd hate to have to put pragmas every place I invoked the macro.
     
    W Karas, Apr 11, 2013
    #1
    1. Advertising

  2. W Karas <> wrote:

    (snip)

    > yada-yada , (exprA ? exprB : 0), yada-yada


    > where exprB has side effects. GCC seems to have no complaints as
    > long as exprB evaluates to a constant value known at compile time.
    > But if exprB has a variable in it, and exprA is false, GCC gives
    > a "value not used in comma expression" warning (using -Wall) or
    > something like that. The -Wno-unused-value option eliminates
    > this warning. I would like to ask 2 questions.


    > 1) What are some problems I might miss by using -Wno-unused-value ?
    > I thought it might disable the warning for unused variables,
    > but that is separate and covered by -Wunused-variables.


    I believe no-unused-value is related to legal but useless expressions
    like:

    x+2;

    I suppose mostly useful for typos, such as when you meant:

    x=2;

    Seems to me that you have to evaluate the cost (looking through
    all the false hits) of warnings against the value (finding something
    that would be very difficult otherwise).

    I believe that no-unused-value specifically excludes function
    calls, which are assumed to have side effects. You might try

    sqrt(2.2);

    to test it.

    > 2) Is there a more targeted way to eliminate this spurious warning?
    > I'd hate to have to put pragmas every place I invoked the macro.


    Personally, I have rarely found use for it. In the EMS (Expanded
    memory) days, I did have macros that expanded to the appropriate
    EMS calls in some cases, or to a constant expression in others.

    I remember warnings, and that was from before gcc.

    -- glen
     
    glen herrmannsfeldt, Apr 11, 2013
    #2
    1. Advertising

  3. W Karas

    W Karas Guest

    On Wednesday, April 10, 2013 7:07:14 PM UTC-4, W Karas wrote:
    > Recently I wrote a macro to set a bit field at an arbitrary location in an array of some unsigned integral type. (Can't show it because it's proprietary.) The bit field is specified as a bit offset from the start of the array, and the number of bits of width. Probably a mistake, but I decided it would (somehow) be more aesthetic if the macro expanded to an expression with side effects (and useless value) rather than a (compound) statement. The expanded macro has multiple instances of this pattern:
    >
    >
    >
    > yada-yada , (exprA ? exprB : 0), yada-yada
    >
    >
    >
    > where exprB has side effects. GCC seems to have no complaints as long asexprB evaluates to a constant value known at compile time. But if exprB has a variable in it, and exprA is false, GCC gives a "value not used in comma expression" warning (using -Wall) or something like that. The -Wno-unused-value option eliminates this warning. I would like to ask 2 questions.
    >
    >
    >
    > 1) What are some problems I might miss by using -Wno-unused-value ? I thought it might disable the warning for unused variables, but that is separate and covered by -Wunused-variables.
    >
    >
    >
    > 2) Is there a more targeted way to eliminate this spurious warning? I'dhate to have to put pragmas every place I invoked the macro.



    Guess I'll do this:

    #if defined(__GNUC__) || defined(__cplusplus__)

    #define NOTHING(TYPE) ((TYPE) nothing_())

    static inline int nothing_(void) { return(0); }

    #else

    #define NOTHING(TYPE) ((TYPE) 0)

    #endif

    and replace the zero with an invocation of the NOTHING macro.
     
    W Karas, Apr 11, 2013
    #3
  4. W Karas

    Ian Collins Guest

    W Karas wrote:
    > Recently I wrote a macro to set a bit field at an arbitrary location
    > in an array of some unsigned integral type. (Can't show it because
    > it's proprietary.) The bit field is specified as a bit offset from
    > the start of the array, and the number of bits of width. Probably a
    > mistake, but I decided it would (somehow) be more aesthetic if the
    > macro expanded to an expression with side effects (and useless value)
    > rather than a (compound) statement. The expanded macro has multiple
    > instances of this pattern:
    >
    > yada-yada , (exprA ? exprB : 0), yada-yada


    I guess the obvious question is why use a macro at all? This looks like
    an obfuscated code competition entry!

    --
    Ian Collins
     
    Ian Collins, Apr 11, 2013
    #4
  5. W Karas

    W Karas Guest

    On Wednesday, April 10, 2013 9:07:22 PM UTC-4, Ian Collins wrote:
    > W Karas wrote:
    >
    > > Recently I wrote a macro to set a bit field at an arbitrary location

    >
    > > in an array of some unsigned integral type. (Can't show it because

    >
    > > it's proprietary.) The bit field is specified as a bit offset from

    >
    > > the start of the array, and the number of bits of width. Probably a

    >
    > > mistake, but I decided it would (somehow) be more aesthetic if the

    >
    > > macro expanded to an expression with side effects (and useless value)

    >
    > > rather than a (compound) statement. The expanded macro has multiple

    >
    > > instances of this pattern:

    >
    > >

    >
    > > yada-yada , (exprA ? exprB : 0), yada-yada

    >
    >
    >
    > I guess the obvious question is why use a macro at all? This looks like
    >
    > an obfuscated code competition entry!
    >
    >
    >
    > --
    >
    > Ian Collins


    If performance matters, and most bit field accesses involve a constant offset and width, the macros are superior to functions. They are also configurable to work with address spaces other than primary memory that may use a word size and byte order different from the CPU executing the C code.
     
    W Karas, Apr 11, 2013
    #5
  6. W Karas

    James Kuyper Guest

    On 04/10/2013 09:48 PM, W Karas wrote:
    ....
    > If performance matters, and most bit field accesses involve a constant offset and width, the macros are superior to functions. They are also configurable to work with address spaces other than primary memory that may use a word size and byte order different from the CPU executing the C code.


    A decent compiler can often give an inline function the same performance
    benefit as a macro, and the function is often far easier to write.
    --
    James Kuyper
     
    James Kuyper, Apr 11, 2013
    #6
  7. W Karas

    Ian Collins Guest

    W Karas wrote:
    > On Wednesday, April 10, 2013 9:07:22 PM UTC-4, Ian Collins wrote:
    >> W Karas wrote:
    >>
    >>> The expanded macro has multiple instances of this pattern:


    >>> yada-yada , (exprA ? exprB : 0), yada-yada


    >> I guess the obvious question is why use a macro at all? This looks like
    >> an obfuscated code competition entry!


    Please fix your quoting!

    > If performance matters, and most bit field accesses involve a
    > constant offset and width, the macros are superior to functions.


    Very unlikely with current optimising compilers.

    > They are also configurable to work with address spaces other than
    > primary memory that may use a word size and byte order different from
    > the CPU executing the C code.


    So can a function.

    --
    Ian Collins
     
    Ian Collins, Apr 11, 2013
    #7
  8. W Karas

    Noob Guest

    W Karas wrote:
    > Recently I wrote a macro to set a bit field at an arbitrary location
    > in an array of some unsigned integral type. (Can't show it because
    > it's proprietary.) The bit field is specified as a bit offset from
    > the start of the array, and the number of bits of width. Probably a
    > mistake, but I decided it would (somehow) be more aesthetic if the
    > macro expanded to an expression with side effects (and useless value)
    > rather than a (compound) statement. The expanded macro has multiple
    > instances of this pattern:
    >
    > yada-yada , (exprA ? exprB : 0), yada-yada


    Please give more details about the macro's specs.

    If I understand your description correctly, the inputs are:

    1) an unsigned {char,short,int,long,long long} array
    2) an offset, in bits
    3) the number of bits affected

    Question #1
    When you say you "set" several bits, does that mean they all
    take the value "1" or do you use "set" in the general sense,
    meaning there's a 4th parameter, the value to set the
    specified bits to? (In the second case, if the value is 0,
    then the macro would actually clear the bits.)

    Question #2
    Can the affected bits span multiple cells?
    For example, suppose we have
    unsigned char arr[128];
    and we want to set bits 5 to 47 in one go
    Does your macro allow that?

    Question #3
    Are there upper bounds on the offset and the width?

    Question #4
    Do you test for out-of-bounds access?
    Suppose we have
    unsigned char arr[2]
    and the macro is used to set bits 5 to 47
    what happens then?

    Regards.
     
    Noob, Apr 11, 2013
    #8
  9. W Karas

    James Kuyper Guest

    On 04/10/2013 07:07 PM, W Karas wrote:
    > Recently I wrote a macro to set a bit field at an arbitrary location
    > in an array of some unsigned integral type. (Can't show it because
    > it's proprietary.) The bit field is specified as a bit offset from
    > the start of the array, and the number of bits of width. Probably a
    > mistake, but I decided it would (somehow) be more aesthetic if the
    > macro expanded to an expression with side effects (and useless value)
    > rather than a (compound) statement. ...


    I agree - that was probably a mistake.

    > ... The expanded macro has multiple
    > instances of this pattern:
    >
    > yada-yada , (exprA ? exprB : 0), yada-yada


    Insofar as the C grammar can be described in terms of precedence, the
    comma operator has absolutely the lowest precedence, so the parentheses
    are unnecessary. They don't hurt anything, and if they make it easier
    for you to understand what you're writing, go ahead, but I wouldn't
    bother with them.

    > where exprB has side effects. GCC seems to have no complaints as
    > long as exprB evaluates to a constant value known at compile time.
    > But if exprB has a variable in it, and exprA is false, GCC gives a
    > "value not used in comma expression" warning (using -Wall) or
    > something like that.


    The sole reason you have the 0 is that you've
    chosen to use the ?: operator, and the sole reason you made that choice
    is because you want evaluation of exprB to depend upon whether or not
    exprA is non-zero. There's a simpler, more direct way to do that, which
    doesn't involve a 0: (exprA && exprB). I've no idea whether that will
    affect the warning message you're getting, but it's worth a try.
    --
    James Kuyper
     
    James Kuyper, Apr 11, 2013
    #9
  10. W Karas

    W Karas Guest

    On Thursday, April 11, 2013 8:16:10 AM UTC-4, James Kuyper wrote:
    > On 04/10/2013 07:07 PM, W Karas wrote:
    >
    > > Recently I wrote a macro to set a bit field at an arbitrary location

    >
    > > in an array of some unsigned integral type. (Can't show it because

    >
    > > it's proprietary.) The bit field is specified as a bit offset from

    >
    > > the start of the array, and the number of bits of width. Probably a

    >
    > > mistake, but I decided it would (somehow) be more aesthetic if the

    >
    > > macro expanded to an expression with side effects (and useless value)

    >
    > > rather than a (compound) statement. ...

    >
    >
    >
    > I agree - that was probably a mistake.


    Then again, when there are 'if' statements within macros, and the condition of the 'if' is a constant that can be evaluated at compile time, you can get "unreachable code" warnings.

    >
    >
    >
    > > ... The expanded macro has multiple

    >
    > > instances of this pattern:

    >
    > >

    >
    > > yada-yada , (exprA ? exprB : 0), yada-yada

    >
    >
    >
    > Insofar as the C grammar can be described in terms of precedence, the
    >
    > comma operator has absolutely the lowest precedence, so the parentheses
    >
    > are unnecessary. They don't hurt anything, and if they make it easier
    >
    > for you to understand what you're writing, go ahead, but I wouldn't
    >
    > bother with them.
    >
    >
    >
    > > where exprB has side effects. GCC seems to have no complaints as

    >
    > > long as exprB evaluates to a constant value known at compile time.

    >
    > > But if exprB has a variable in it, and exprA is false, GCC gives a

    >
    > > "value not used in comma expression" warning (using -Wall) or

    >
    > > something like that.

    >
    >
    >
    > The sole reason you have the 0 is that you've
    >
    > chosen to use the ?: operator, and the sole reason you made that choice
    >
    > is because you want evaluation of exprB to depend upon whether or not
    >
    > exprA is non-zero. There's a simpler, more direct way to do that, which
    >
    > doesn't involve a 0: (exprA && exprB). I've no idea whether that will
    >
    > affect the warning message you're getting, but it's worth a try.
    >
    > --
    >
    > James Kuyper
     
    W Karas, Apr 11, 2013
    #10
  11. W Karas

    James Kuyper Guest

    On 04/11/2013 01:23 PM, W Karas wrote:
    > On Thursday, April 11, 2013 8:16:10 AM UTC-4, James Kuyper wrote:
    >> On 04/10/2013 07:07 PM, W Karas wrote:
    >>> Recently I wrote a macro to set a bit field at an arbitrary location
    >>> in an array of some unsigned integral type. (Can't show it because
    >>> it's proprietary.) The bit field is specified as a bit offset from
    >>> the start of the array, and the number of bits of width. Probably a
    >>> mistake, but I decided it would (somehow) be more aesthetic if the
    >>> macro expanded to an expression with side effects (and useless value)
    >>> rather than a (compound) statement. ...

    >>
    >>
    >>
    >> I agree - that was probably a mistake.

    >
    > Then again, when there are 'if' statements within macros, and the condition of the 'if' is a constant that can be evaluated at compile time, you can get "unreachable code" warnings.


    Again, that's something you could probably avoid using an inline
    function rather than a macro. Depending upon the details of the macro
    (which you haven't given us), if it were converted into an inline
    function, the compiler might not even put "constant expression" together
    with "if()" until after it's inlined the code, at which point you're
    unlikely to get that particular warning.
    --
    James Kuyper
     
    James Kuyper, Apr 11, 2013
    #11
  12. W Karas

    W Karas Guest

    On Thursday, April 11, 2013 1:42:56 PM UTC-4, James Kuyper wrote:
    > On 04/11/2013 01:23 PM, W Karas wrote:
    >
    > > On Thursday, April 11, 2013 8:16:10 AM UTC-4, James Kuyper wrote:

    >
    > >> On 04/10/2013 07:07 PM, W Karas wrote:

    >
    > >>> Recently I wrote a macro to set a bit field at an arbitrary location

    >
    > >>> in an array of some unsigned integral type. (Can't show it because

    >
    > >>> it's proprietary.) The bit field is specified as a bit offset from

    >
    > >>> the start of the array, and the number of bits of width. Probably a

    >
    > >>> mistake, but I decided it would (somehow) be more aesthetic if the

    >
    > >>> macro expanded to an expression with side effects (and useless value)

    >
    > >>> rather than a (compound) statement. ...

    >
    > >>

    >
    > >>

    >
    > >>

    >
    > >> I agree - that was probably a mistake.

    >
    > >

    >
    > > Then again, when there are 'if' statements within macros, and the condition of the 'if' is a constant that can be evaluated at compile time, you can get "unreachable code" warnings.

    >
    >
    >
    > Again, that's something you could probably avoid using an inline
    >
    > function rather than a macro. Depending upon the details of the macro
    >
    > (which you haven't given us), if it were converted into an inline
    >
    > function, the compiler might not even put "constant expression" together
    >
    > with "if()" until after it's inlined the code, at which point you're
    >
    > unlikely to get that particular warning.
    >
    > --
    >
    > James Kuyper


    Can't show the actual code, it's proprietary work stuff.

    With the compilers we use (GCC, Green Hills) I've been very disappointed with how they handle nested inline functions.
     
    W Karas, Apr 11, 2013
    #12
  13. W Karas

    Jorgen Grahn Guest

    On Thu, 2013-04-11, W Karas wrote:
    ....
    > With the compilers we use (GCC, Green Hills) I've been very
    > disappointed with how they handle nested inline functions.


    Recent or very old gcc? I'd expect a recent one to be good at
    inlining, because it's a C feature that's used a lot these days, and
    because it's even /more/ used in the C++ half of gcc.

    I'm also asking because I know from experience that in the embedded
    space you often find yourself locked to outdated tools.

    Of course I'm biased: I use gcc a lot, and while I do it on "embedded"
    systems, these systems have powerful CPUs belonging to well-known and
    well-supported families.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, Apr 11, 2013
    #13
  14. W Karas

    Ike Naar Guest

    On 2013-04-11, W Karas <> wrote:
    > Can't show the actual code, it's proprietary work stuff.


    Then ask for help at work.
     
    Ike Naar, Apr 11, 2013
    #14
  15. W Karas

    Tim Rentsch Guest

    W Karas <> writes:

    > Recently I wrote a macro to set a bit field at an arbitrary
    > location in an array of some unsigned integral type. (Can't show
    > it because it's proprietary.) The bit field is specified as a bit
    > offset from the start of the array, and the number of bits of
    > width. Probably a mistake, but I decided it would (somehow) be
    > more aesthetic if the macro expanded to an expression with side
    > effects (and useless value) rather than a (compound) statement.
    > The expanded macro has multiple instances of this pattern:
    >
    > yada-yada , (exprA ? exprB : 0), yada-yada
    >
    > where exprB has side effects. GCC seems to have no complaints as
    > long as exprB evaluates to a constant value known at compile time.
    > But if exprB has a variable in it, and exprA is false, GCC gives a
    > "value not used in comma expression" warning (using -Wall) or
    > something like that. The -Wno-unused-value option eliminates this
    > warning. I would like to ask 2 questions.
    >
    > 1) What are some problems I might miss by using -Wno-unused-value
    > ? I thought it might disable the warning for unused variables,
    > but that is separate and covered by -Wunused-variables.
    >
    > 2) Is there a more targeted way to eliminate this spurious
    > warning? I'd hate to have to put pragmas every place I invoked
    > the macro.


    Did you read the gcc man page? The one I looked at explains
    what to do in the code to inhibit the warning for a specific
    instance.
     
    Tim Rentsch, Apr 12, 2013
    #15
  16. In article <>,
    Jorgen Grahn <> wrote:

    >I'm also asking because I know from experience that in the embedded
    >space you often find yourself locked to outdated tools.


    Testify, brother! Working in C++ right now, with no STL. :(

    --
    -Ed Falk,
    http://thespamdiaries.blogspot.com/
     
    Edward A. Falk, Apr 12, 2013
    #16
  17. W Karas

    Noob Guest

    W Karas wrote:

    > Can't show the actual code, it's proprietary work stuff.


    Can you comment on the specs in my direct reply to you?
     
    Noob, Apr 12, 2013
    #17
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Charlie Zender
    Replies:
    12
    Views:
    1,086
    Peter Pichler
    Jan 3, 2004
  2. Charlie Zender

    Removing GCC compiler warnings from fabsf(), sqrtf()...

    Charlie Zender, Jan 2, 2004, in forum: C Programming
    Replies:
    8
    Views:
    636
    Ben Pfaff
    Jan 4, 2004
  3. G Patel

    comma operator and assignment operator

    G Patel, Feb 7, 2005, in forum: C Programming
    Replies:
    4
    Views:
    492
    Barry Schwarz
    Feb 8, 2005
  4. Warnings with gcc

    , Nov 22, 2005, in forum: C Programming
    Replies:
    34
    Views:
    1,382
    Flash Gordon
    Nov 25, 2005
  5. Ted Sung
    Replies:
    1
    Views:
    317
    Sherm Pendley
    Aug 30, 2004
Loading...

Share This Page