New gcc 4.0.0 warnings seem spurious

New gcc 4.0.0 warnings seem spurious

[Bruce Lilly]

Demonstration code:
--------------------------
#define AAA 0x1U
#define BBB 0x2U

struct foo {
    unsigned int bar:8;
};

struct foo foos[] = {
    { ~(AAA) },
    { ~(BBB) },
    { ~(AAA|BBB) },
    { ~(AAA&BBB) }
};
--------------------------

compiling with gcc 3.x produced no warnings, as expected (no problems as
all values fit easily within the defined structure's bit field).

gcc 4.0.0 produces:

gcctest.c:9: warning: large integer implicitly truncated to unsigned type
gcctest.c:10: warning: large integer implicitly truncated to unsigned type
gcctest.c:11: warning: large integer implicitly truncated to unsigned type
gcctest.c:12: warning: large integer implicitly truncated to unsigned type

Re: New gcc 4.0.0 warnings seem spurious

[Joseph S. Myers]

On Tue, 26 Apr 2005, Bruce Lilly wrote:

> Demonstration code:
> --------------------------
> #define AAA 0x1U
> #define BBB 0x2U
> 
> struct foo {
>     unsigned int bar:8;
> };
> 
> struct foo foos[] = {
>     { ~(AAA) },
>     { ~(BBB) },
>     { ~(AAA|BBB) },
>     { ~(AAA&BBB) }
> };
> --------------------------
> 
> compiling with gcc 3.x produced no warnings, as expected (no problems as
> all values fit easily within the defined structure's bit field).

I don't see why you think the warnings are spurious.  ~(AAA), for example, 
is 4294967294, which being greater than 255 certainly does not fit within 
the type unsigned:8.  Previous GCC versions had a long-known bug whereby 
they did not diagnose this; that bug has been fixed in GCC 4.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    joseph@codesourcery.com (CodeSourcery mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

Re: New gcc 4.0.0 warnings seem spurious

[Bruce Lilly]

On Tue April 26 2005 11:10, Joseph S. Myers wrote:
> On Tue, 26 Apr 2005, Bruce Lilly wrote:
> 
> > Demonstration code:
> > --------------------------
> > #define AAA 0x1U
> > #define BBB 0x2U
> > 
> > struct foo {
> >     unsigned int bar:8;
> > };
> > 
> > struct foo foos[] = {
> >     { ~(AAA) },
> >     { ~(BBB) },
> >     { ~(AAA|BBB) },
> >     { ~(AAA&BBB) }
> > };
> > --------------------------
> > 
> > compiling with gcc 3.x produced no warnings, as expected (no problems as
> > all values fit easily within the defined structure's bit field).
> 
> I don't see why you think the warnings are spurious.  ~(AAA), for example, 
> is 4294967294,

No, in this context it is 254 (an 8-bit unsigned field with the LSB clear).

> which being greater than 255 certainly does not fit within  
> the type unsigned:8.

But 254 is certainly < 255.  The 'U' in the constant simply means unsigned;
if it had been specified as "LU" you might have a point.  But it wasn't.

> Previous GCC versions had a long-known bug whereby  
> they did not diagnose this; that bug has been fixed in GCC 4.

Looks more like several bugs were introduced; consider:

#if 0
#define AAA 0x1U
#define BBB 0x2U
#else
static const unsigned char AAA = 0x1U;
static const unsigned char BBB = 0x2U;
#endif

struct foo {
    unsigned int bar:8;
};

struct foo foos[] = {
    { ~(AAA) },
    { ~(BBB) },
    { ~(AAA|BBB) },
    { ~(AAA&BBB) }
};

gcc 4.0.0 reports:

gcctest.c:14: error: initializer element is not constant
gcctest.c:14: error: (near initialization for 'foos[0].bar')
gcctest.c:15: error: initializer element is not constant
gcctest.c:15: error: (near initialization for 'foos[1].bar')
gcctest.c:16: error: initializer element is not constant
gcctest.c:16: error: (near initialization for 'foos[2].bar')
gcctest.c:17: error: initializer element is not constant
gcctest.c:17: error: (near initialization for 'foos[3].bar')

Now it's claiming that two *explicitly declared* const values aren't
constant!

Re: New gcc 4.0.0 warnings seem spurious

[Zack Weinberg]

Bruce Lilly <blilly@erols.com> writes:

>> I don't see why you think the warnings are spurious.  ~(AAA), for example, 
>> is 4294967294,
>
> No, in this context it is 254 (an 8-bit unsigned field with the LSB clear).

C does not work the way you think.  AAA has type unsigned int.  The
expression ~(AAA) also has type unsigned int, and the value that
Joseph stated.  It always has that type and value, no matter what
context it appears in.  The initializer thus tries to give a variable
with type unsigned:8 a value that it cannot hold.  The diagnostic is
correct.

> static const unsigned char AAA = 0x1U;
> static const unsigned char BBB = 0x2U;

Again, C does not work the way you think.  These are not constants.
They are variables, which happen to be read-only.  You cannot use them
in initializers, just as you cannot use any other variable in an
initializer.

Furthermore, with that definition, AAA has type unsigned char, but
~(AAA) has type *signed* int and the value -2, because all arithmetic
operations on types smaller than int, signed or unsigned, are first
promoted to int (this is a slight simplification but is correct as far
as it goes).

zw

Re: New gcc 4.0.0 warnings seem spurious

[Vincent Lefevre]

On 2005-04-26 13:15:43 -0700, Zack Weinberg wrote:
> The initializer thus tries to give a variable with type unsigned:8
> a value that it cannot hold. The diagnostic is correct.

However it is correct to store any integer to an unsigned variable,
even if the original value cannot be represented. Therefore the
diagnostic isn't necessary, and IMHO, there should be a way to disable
it (possibly locally to some part of the program).

> Bruce Lilly <blilly@erols.com> writes:
> > static const unsigned char AAA = 0x1U;
> > static const unsigned char BBB = 0x2U;
> 
> Again, C does not work the way you think.  These are not constants.

But if they are never modified, they evaluate to constants, right?

The fact that they are not considered as constant expressions,
is it due to the fact that the environment is allowed to modify
them?

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: New gcc 4.0.0 warnings seem spurious

[Zack Weinberg]

Vincent Lefevre <vincent+gcc@vinc17.org> writes:

> On 2005-04-26 13:15:43 -0700, Zack Weinberg wrote:
>> The initializer thus tries to give a variable with type unsigned:8
>> a value that it cannot hold. The diagnostic is correct.
>
> However it is correct to store any integer to an unsigned variable,
> even if the original value cannot be represented.

If that operation occurs at runtime it has a well-defined result.
If that operation occurs at compile time, as part of an initializer
expression, the overflow must be diagnosed (C99 6.6p4 - constraint
violation).  Your request for a way to turn off the diagnostic is
reasonable; you could make it happen sooner by helping out with DJ's
fine-grained warning control project.

> Therefore the diagnostic isn't necessary, and IMHO, there should be
> a way to disable it (possibly locally to some part of the program).
>
>> Bruce Lilly <blilly@erols.com> writes:
>> > static const unsigned char AAA = 0x1U;
>> > static const unsigned char BBB = 0x2U;
>> 
>> Again, C does not work the way you think.  These are not constants.
>
> But if they are never modified, they evaluate to constants, right?

The compiler is allowed, but not required, to replace references to
them with their known values.

> The fact that they are not considered as constant expressions,
> is it due to the fact that the environment is allowed to modify
> them?

No (and in fact the environment is not allowed to do that).  It is
because the set of things that are allowed in constant expressions are
explicitly listed in C99 6.6, and read-only variables aren't one of
the things on the list.

zw

Re: New gcc 4.0.0 warnings seem spurious

[Vincent Lefevre]

On 2005-04-27 03:37:15 -0700, Zack Weinberg wrote:
> Vincent Lefevre <vincent+gcc@vinc17.org> writes:
> > However it is correct to store any integer to an unsigned variable,
> > even if the original value cannot be represented.
> 
> If that operation occurs at runtime it has a well-defined result.

And gcc 4 doesn't output a diagnostic in this case?

> If that operation occurs at compile time, as part of an initializer
> expression, the overflow must be diagnosed (C99 6.6p4 - constraint
> violation).

Before the conversion, the value is representable in the type of
the expression, and after the conversion (which is well-defined),
it is still representable in the (new) type of the expression.
6.7.8#11 mentions the possible conversion. So, I disagree here.

> > The fact that they are not considered as constant expressions,
> > is it due to the fact that the environment is allowed to modify
> > them?
> 
> No (and in fact the environment is not allowed to do that).  It is
> because the set of things that are allowed in constant expressions are
> explicitly listed in C99 6.6, and read-only variables aren't one of
> the things on the list.

The only two constraints in 6.6 are:

       [#3] Constant  expressions  shall  not  contain  assignment,
       increment,  decrement,  function-call,  or  comma operators,
       except when they are contained within a  subexpression  that
       is not evaluated.86)

       [#4] Each constant expression shall evaluate to  a  constant
       that is in the range of representable values for its type.

#3 doesn't include variables. #4 is OK if one considers that the
value cannot be modified.

#6 adds other requirements, but this is out of the scope of the
given diagnostic (which complained about an expression not being a
constant -- not because it wasn't an integer constant expression).
Couldn't the expression fall into #10 with some implementations?

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: New gcc 4.0.0 warnings seem spurious

[Andrew Haley]

Vincent Lefevre writes:
 > On 2005-04-27 03:37:15 -0700, Zack Weinberg wrote:
 > > Vincent Lefevre <vincent+gcc@vinc17.org> writes:
 > > > However it is correct to store any integer to an unsigned variable,
 > > > even if the original value cannot be represented.
 > > 
 > > If that operation occurs at runtime it has a well-defined result.
 > 
 > And gcc 4 doesn't output a diagnostic in this case?
 > 
 > > If that operation occurs at compile time, as part of an initializer
 > > expression, the overflow must be diagnosed (C99 6.6p4 - constraint
 > > violation).
 > 
 > Before the conversion, the value is representable in the type of
 > the expression, and after the conversion (which is well-defined),
 > it is still representable in the (new) type of the expression.
 > 6.7.8#11 mentions the possible conversion. So, I disagree here.
 > 
 > > > The fact that they are not considered as constant expressions,
 > > > is it due to the fact that the environment is allowed to modify
 > > > them?
 > > 
 > > No (and in fact the environment is not allowed to do that).  It is
 > > because the set of things that are allowed in constant expressions are
 > > explicitly listed in C99 6.6, and read-only variables aren't one of
 > > the things on the list.
 > 
 > The only two constraints in 6.6 are:
 > 
 >        [#3] Constant  expressions  shall  not  contain  assignment,
 >        increment,  decrement,  function-call,  or  comma operators,
 >        except when they are contained within a  subexpression  that
 >        is not evaluated.86)
 > 
 >        [#4] Each constant expression shall evaluate to  a  constant
 >        that is in the range of representable values for its type.
 > 
 > #3 doesn't include variables. #4 is OK if one considers that the
 > value cannot be modified.
 > 
 > #6 adds other requirements, but this is out of the scope of the
 > given diagnostic (which complained about an expression not being a
 > constant -- not because it wasn't an integer constant expression).

6.7.8 Para 4.  All the expressions for an initializer for an object
    that has static storage duration shall be constant expressions ...

6.6 Para 6.  An integer constant expression shall have integer type
  and shall only have operands that are inetger constants, enumeration
  constants, character constants, sizeof expressions whose results are
  integer constants, and floating-point constans that are the
  immediate operands of casts ...

 > Couldn't the expression fall into #10 with some implementations?

Probably, but that would be yet another gcc-local extension.

Andrew.

Re: New gcc 4.0.0 warnings seem spurious

[Vincent Lefevre]

On 2005-04-27 12:29:53 +0100, Andrew Haley wrote:
> Vincent Lefevre writes:
>  > The only two constraints in 6.6 are:
>  > 
>  >        [#3] Constant  expressions  shall  not  contain  assignment,
>  >        increment,  decrement,  function-call,  or  comma operators,
>  >        except when they are contained within a  subexpression  that
>  >        is not evaluated.86)
>  > 
>  >        [#4] Each constant expression shall evaluate to  a  constant
>  >        that is in the range of representable values for its type.
>  > 
>  > #3 doesn't include variables. #4 is OK if one considers that the
>  > value cannot be modified.
>  > 
>  > #6 adds other requirements, but this is out of the scope of the
>  > given diagnostic (which complained about an expression not being a
>  > constant -- not because it wasn't an integer constant expression).
> 
> 6.7.8 Para 4.  All the expressions for an initializer for an object
>     that has static storage duration shall be constant expressions ...
                                                ^^^^^^^^^^^^^^^^^^^^
It is said "constant expressions", not "integer constant expressions".

> 6.6 Para 6.  An integer constant expression shall have integer type
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   and shall only have operands that are inetger constants, enumeration
>   constants, character constants, sizeof expressions whose results are
>   integer constants, and floating-point constans that are the
>   immediate operands of casts ...

#6 is about an *integer* constant expression.

>  > Couldn't the expression fall into #10 with some implementations?
> 
> Probably, but that would be yet another gcc-local extension.

Yes, but the diagnostic should be more accurate.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: New gcc 4.0.0 warnings seem spurious

[Gabriel Dos Reis]

Vincent Lefevre <vincent+gcc@vinc17.org> writes:

| On 2005-04-27 12:29:53 +0100, Andrew Haley wrote:
| > Vincent Lefevre writes:
| >  > The only two constraints in 6.6 are:
| >  > 
| >  >        [#3] Constant  expressions  shall  not  contain  assignment,
| >  >        increment,  decrement,  function-call,  or  comma operators,
| >  >        except when they are contained within a  subexpression  that
| >  >        is not evaluated.86)
| >  > 
| >  >        [#4] Each constant expression shall evaluate to  a  constant
| >  >        that is in the range of representable values for its type.
| >  > 
| >  > #3 doesn't include variables. #4 is OK if one considers that the
| >  > value cannot be modified.
| >  > 
| >  > #6 adds other requirements, but this is out of the scope of the
| >  > given diagnostic (which complained about an expression not being a
| >  > constant -- not because it wasn't an integer constant expression).
| > 
| > 6.7.8 Para 4.  All the expressions for an initializer for an object
| >     that has static storage duration shall be constant expressions ...
|                                                 ^^^^^^^^^^^^^^^^^^^^
| It is said "constant expressions", not "integer constant expressions".

And an integer constant expression is not a constant expression in
your copy of the C standard?

| > 6.6 Para 6.  An integer constant expression shall have integer type
|                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^
| >   and shall only have operands that are inetger constants, enumeration
| >   constants, character constants, sizeof expressions whose results are
| >   integer constants, and floating-point constans that are the
| >   immediate operands of casts ...
| 
| #6 is about an *integer* constant expression.

And?

-- Gaby

Re: New gcc 4.0.0 warnings seem spurious

[Vincent Lefevre]

On 2005-04-27 15:41:06 +0200, Gabriel Dos Reis wrote:
> Vincent Lefevre <vincent+gcc@vinc17.org> writes:
> | It is said "constant expressions", not "integer constant expressions".
> 
> And an integer constant expression is not a constant expression in
> your copy of the C standard?

What you are saying is nonsense. The point is that a constant
expression isn't necessarily an integer constant expression.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: New gcc 4.0.0 warnings seem spurious

[Gabriel Dos Reis]

Vincent Lefevre <vincent+gcc@vinc17.org> writes:

| On 2005-04-27 15:41:06 +0200, Gabriel Dos Reis wrote:
| > Vincent Lefevre <vincent+gcc@vinc17.org> writes:
| > | It is said "constant expressions", not "integer constant expressions".
| > 
| > And an integer constant expression is not a constant expression in
| > your copy of the C standard?
| 
| What you are saying is nonsense.

I would be glad you explain why it is nonsense, not just because you
assert it. 

| The point is that a constant
| expression isn't necessarily an integer constant expression.

-- Gaby

Re: New gcc 4.0.0 warnings seem spurious

[Gabriel Dos Reis]

Vincent Lefevre <vincent+gcc@vinc17.org> writes:

| On 2005-04-27 03:37:15 -0700, Zack Weinberg wrote:
| > Vincent Lefevre <vincent+gcc@vinc17.org> writes:
| > > However it is correct to store any integer to an unsigned variable,
| > > even if the original value cannot be represented.
| > 
| > If that operation occurs at runtime it has a well-defined result.
| 
| And gcc 4 doesn't output a diagnostic in this case?

Why shall it?

| 
| > If that operation occurs at compile time, as part of an initializer
| > expression, the overflow must be diagnosed (C99 6.6p4 - constraint
| > violation).
| 
| Before the conversion, the value is representable in the type of
| the expression, and after the conversion (which is well-defined),
| it is still representable in the (new) type of the expression.
| 6.7.8#11 mentions the possible conversion. So, I disagree here.
| 
| > > The fact that they are not considered as constant expressions,
| > > is it due to the fact that the environment is allowed to modify
| > > them?
| > 
| > No (and in fact the environment is not allowed to do that).  It is
| > because the set of things that are allowed in constant expressions are
| > explicitly listed in C99 6.6, and read-only variables aren't one of
| > the things on the list.
| 
| The only two constraints in 6.6 are:

In my version of the C standard, 6.6 contains *at least* these two
constraints
       Semantics

       [#5] An expression that evaluates to a constant is  required
       in  several contexts.  If a floating expression is evaluated
       in the translation environment, the arithmetic precision and
       range  shall  be at least as great as if the expression were
       being evaluated in the execution environment.

       [#6] An integer constant expression96)  shall  have  integer
       type   and   shall  only  have  operands  that  are  integer
       constants,  enumeration  constants,   character   constants,
       sizeof  expressions whose results are integer constants, and
       floating constants that are the immediate operands of casts.
       Cast  operators in an integer constant expression shall only
       convert arithmetic types to integer types, except as part of
       an operand to the sizeof operator.

Clearly, 6.6/6 rules out AAA from being an integer constant.

| 
|        [#3] Constant  expressions  shall  not  contain  assignment,
|        increment,  decrement,  function-call,  or  comma operators,
|        except when they are contained within a  subexpression  that
|        is not evaluated.86)
| 
|        [#4] Each constant expression shall evaluate to  a  constant
|        that is in the range of representable values for its type.
| 
| #3 doesn't include variables. #4 is OK if one considers that the
| value cannot be modified.
| 
| #6 adds other requirements, but this is out of the scope of the
| given diagnostic (which complained about an expression not being a
| constant -- not because it wasn't an integer constant expression).
| Couldn't the expression fall into #10 with some implementations?

Huh?

-- Gaby

Re: New gcc 4.0.0 warnings seem spurious

[Vincent Lefevre]

On 2005-04-27 15:26:39 +0200, Gabriel Dos Reis wrote:
> Vincent Lefevre <vincent+gcc@vinc17.org> writes:
> 
> | On 2005-04-27 03:37:15 -0700, Zack Weinberg wrote:
> | > Vincent Lefevre <vincent+gcc@vinc17.org> writes:
> | > > However it is correct to store any integer to an unsigned variable,
> | > > even if the original value cannot be represented.
> | > 
> | > If that operation occurs at runtime it has a well-defined result.
> | 
> | And gcc 4 doesn't output a diagnostic in this case?
> 
> Why shall it?

No reason. I was just asking for a confirmation (I don't have gcc 4
here yet).

> In my version of the C standard, 6.6 contains *at least* these two
> constraints
>        Semantics
> 
>        [#5] An expression that evaluates to a constant is  required
>        in  several contexts.  If a floating expression is evaluated
>        in the translation environment, the arithmetic precision and
>        range  shall  be at least as great as if the expression were
>        being evaluated in the execution environment.
> 
>        [#6] An integer constant expression96)  shall  have  integer
>        type   and   shall  only  have  operands  that  are  integer
>        constants,  enumeration  constants,   character   constants,
>        sizeof  expressions whose results are integer constants, and
>        floating constants that are the immediate operands of casts.
>        Cast  operators in an integer constant expression shall only
>        convert arithmetic types to integer types, except as part of
>        an operand to the sizeof operator.
> 
> Clearly, 6.6/6 rules out AAA from being an integer constant.

It rules out AAA from being an integer constant expression.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: New gcc 4.0.0 warnings seem spurious

[Neil Booth]

Vincent Lefevre wrote:-

> 
> Before the conversion, the value is representable in the type of
> the expression, and after the conversion (which is well-defined),
> it is still representable in the (new) type of the expression.
> 6.7.8#11 mentions the possible conversion. So, I disagree here.

Warnings aren't only intended for undefined things; they're
supposed to point out suspect constructs.  If my compiler didn't
warn about assigning a 32-bit quantity to an 8-bit one I'd
think it a poor implementation.

Even better, you can turn of the warning with a cast, making your
intent explicit to the compiler, so there's every reason to have
it on by default.

Neil.

Re: New gcc 4.0.0 warnings seem spurious

[Mike Stump]

On Apr 27, 2005, at 5:15 AM, Neil Booth wrote:
> Even better, you can turn of the warning with a cast, making your
> intent explicit to the compiler, so there's every reason to have
> it on by default.

And, if you don't like casts, you can (...)&255 or whatever.

Re: New gcc 4.0.0 warnings seem spurious

[Vincent Lefevre]

On 2005-04-27 14:30:01 -0700, Mike Stump wrote:
> On Apr 27, 2005, at 5:15 AM, Neil Booth wrote:
> >Even better, you can turn of the warning with a cast, making your
> >intent explicit to the compiler, so there's every reason to have
> >it on by default.
> 
> And, if you don't like casts, you can (...)&255 or whatever.

This is quite dirty if the type comes from an internal structure
of some library, where the size of the integer may depend on the
architecture or may change in the future... Do you see a better
solution?

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: New gcc 4.0.0 warnings seem spurious

[Gabriel Dos Reis]

Zack Weinberg <zack@codesourcery.com> writes:

[...]

| >> Bruce Lilly <blilly@erols.com> writes:
| >> > static const unsigned char AAA = 0x1U;
| >> > static const unsigned char BBB = 0x2U;
| >> 
| >> Again, C does not work the way you think.  These are not constants.
| >
| > But if they are never modified, they evaluate to constants, right?
| 
| The compiler is allowed, but not required, to replace references to
| them with their known values.

Yes, however this

   enum { V = AAA };

requires a diagnostic.

-- Gaby

Re: New gcc 4.0.0 warnings seem spurious

[Andrew Haley]

Vincent Lefevre writes:
 > On 2005-04-26 13:15:43 -0700, Zack Weinberg wrote:
 > > The initializer thus tries to give a variable with type unsigned:8
 > > a value that it cannot hold. The diagnostic is correct.
 > 
 > However it is correct to store any integer to an unsigned variable,
 > even if the original value cannot be represented.

It's legal.  That's why we compile it and don't issue an error.

 > Therefore the diagnostic isn't necessary,

Warnings are to help the programmer see where there is some code that,
although not necessarily an error, may require some attention.  This
is a classic case of such a warning.  This warning really does
indicate to the programmer that there might be a real problem.

 > and IMHO, there should be a way to disable it (possibly locally to
 > some part of the program).

Why not just fix the code?

 > > Bruce Lilly <blilly@erols.com> writes:
 > > > static const unsigned char AAA = 0x1U;
 > > > static const unsigned char BBB = 0x2U;
 > > 
 > > Again, C does not work the way you think.  These are not constants.
 > 
 > But if they are never modified, they evaluate to constants, right?
 > 
 > The fact that they are not considered as constant expressions,
 > is it due to the fact that the environment is allowed to modify
 > them?

It's due to what the C standard says.  A const variable in C isn't a
constant, it's just a read-only variable.

Andrew.

Re: New gcc 4.0.0 warnings seem spurious

[Vincent Lefevre]

On 2005-04-27 11:37:51 +0100, Andrew Haley wrote:
> Warnings are to help the programmer see where there is some code that,
> although not necessarily an error, may require some attention.  This
> is a classic case of such a warning.  This warning really does
> indicate to the programmer that there might be a real problem.

On the other hand, too many warnings may annoy the programmer and have
the opposite effect.

>  > and IMHO, there should be a way to disable it (possibly locally to
>  > some part of the program).
> 
> Why not just fix the code?

I don't like the word "fix" since it is correct. It could be probably
OK here, but not necessarily a good thing in other contexts. In other
places, spurious warnings given by gcc cannot be avoidable.

>  > But if they are never modified, they evaluate to constants, right?
>  > 
>  > The fact that they are not considered as constant expressions,
>  > is it due to the fact that the environment is allowed to modify
>  > them?
> 
> It's due to what the C standard says.  A const variable in C isn't a
> constant, it's just a read-only variable.

1+1 isn't a constant either, but is allowed anyway.
I'm talking about constant *expressions*.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: New gcc 4.0.0 warnings seem spurious

[Andrew Haley]

Vincent Lefevre writes:
 > On 2005-04-27 11:37:51 +0100, Andrew Haley wrote:
 > > Warnings are to help the programmer see where there is some code that,
 > > although not necessarily an error, may require some attention.  This
 > > is a classic case of such a warning.  This warning really does
 > > indicate to the programmer that there might be a real problem.
 > 
 > On the other hand, too many warnings may annoy the programmer and have
 > the opposite effect.

Yes, but this isn't an example of a spurious warning.  It's a really
good warning, one that ought to be given.

 > >  > and IMHO, there should be a way to disable it (possibly locally to
 > >  > some part of the program).
 > > 
 > > Why not just fix the code?
 > 
 > I don't like the word "fix" since it is correct.

But that applies to most warnings.

  if (a = b)  

is correct too.

 > >  > But if they are never modified, they evaluate to constants, right?
 > >  > 
 > >  > The fact that they are not considered as constant expressions,
 > >  > is it due to the fact that the environment is allowed to modify
 > >  > them?
 > > 
 > > It's due to what the C standard says.  A const variable in C isn't a
 > > constant, it's just a read-only variable.
 > 
 > 1+1 isn't a constant either, but is allowed anyway.

You said "if they are never modified, they evaluate to constants,
right?"  To which the correct answer is "no, they don't".

Andrew.

Re: New gcc 4.0.0 warnings seem spurious

[Vincent Lefevre]

On 2005-04-27 12:34:14 +0100, Andrew Haley wrote:
> You said "if they are never modified, they evaluate to constants,
> right?"  To which the correct answer is "no, they don't".

Why not?

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: New gcc 4.0.0 warnings seem spurious

[Gabriel Dos Reis]

Vincent Lefevre <vincent+gcc@vinc17.org> writes:

| On 2005-04-27 12:34:14 +0100, Andrew Haley wrote:
| > You said "if they are never modified, they evaluate to constants,
| > right?"  To which the correct answer is "no, they don't".
| 
| Why not?

I think the answer to that question was in the part you snippet from
his message.

-- Gaby

Re: New gcc 4.0.0 warnings seem spurious

[Vincent Lefevre]

On 2005-04-27 15:44:12 +0200, Gabriel Dos Reis wrote:
> Vincent Lefevre <vincent+gcc@vinc17.org> writes:
> 
> | On 2005-04-27 12:34:14 +0100, Andrew Haley wrote:
> | > You said "if they are never modified, they evaluate to constants,
> | > right?"  To which the correct answer is "no, they don't".
> | 
> | Why not?
> 
> I think the answer to that question was in the part you snippet from
> his message.

No.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: New gcc 4.0.0 warnings seem spurious

[Gabriel Dos Reis]

Vincent Lefevre <vincent+gcc@vinc17.org> writes:

| On 2005-04-27 15:44:12 +0200, Gabriel Dos Reis wrote:
| > Vincent Lefevre <vincent+gcc@vinc17.org> writes:
| > 
| > | On 2005-04-27 12:34:14 +0100, Andrew Haley wrote:
| > | > You said "if they are never modified, they evaluate to constants,
| > | > right?"  To which the correct answer is "no, they don't".
| > | 
| > | Why not?
| > 
| > I think the answer to that question was in the part you snippet from
| > his message.
| 
| No.

If you can't see it, you're out of luck.  We can't help you.

-- Gaby

Re: New gcc 4.0.0 warnings seem spurious

[Gabriel Dos Reis]

Vincent Lefevre <vincent+gcc@vinc17.org> writes:

[...]

| >  > But if they are never modified, they evaluate to constants, right?
| >  > 
| >  > The fact that they are not considered as constant expressions,
| >  > is it due to the fact that the environment is allowed to modify
| >  > them?
| > 
| > It's due to what the C standard says.  A const variable in C isn't a
| > constant, it's just a read-only variable.
| 
| 1+1 isn't a constant either

It is an integer constant expression, and its evaluation yields a
constant (see 6.6).  Can you explain why you believe that is false?

-- Gaby

Re: New gcc 4.0.0 warnings seem spurious

[Vincent Lefevre]

On 2005-04-27 15:30:39 +0200, Gabriel Dos Reis wrote:
> Vincent Lefevre <vincent+gcc@vinc17.org> writes:
> 
> [...]
> 
> | >  > But if they are never modified, they evaluate to constants, right?
> | >  > 
> | >  > The fact that they are not considered as constant expressions,
> | >  > is it due to the fact that the environment is allowed to modify
> | >  > them?
> | > 
> | > It's due to what the C standard says.  A const variable in C isn't a
> | > constant, it's just a read-only variable.
> | 
> | 1+1 isn't a constant either
> 
> It is an integer constant expression, and its evaluation yields a
> constant (see 6.6).  Can you explain why you believe that is false?

I never said that it was false. Could you please read messages
before replying?

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: New gcc 4.0.0 warnings seem spurious

[Gabriel Dos Reis]

Vincent Lefevre <vincent+gcc@vinc17.org> writes:

| On 2005-04-27 15:30:39 +0200, Gabriel Dos Reis wrote:
| > Vincent Lefevre <vincent+gcc@vinc17.org> writes:
| > 
| > [...]
| > 
| > | >  > But if they are never modified, they evaluate to constants, right?
| > | >  > 
| > | >  > The fact that they are not considered as constant expressions,
| > | >  > is it due to the fact that the environment is allowed to modify
| > | >  > them?
| > | > 
| > | > It's due to what the C standard says.  A const variable in C isn't a
| > | > constant, it's just a read-only variable.
| > | 
| > | 1+1 isn't a constant either
| > 
| > It is an integer constant expression, and its evaluation yields a
| > constant (see 6.6).  Can you explain why you believe that is false?
| 
| I never said that it was false.

Ah, then what exactly is your point?

| Could you please read messages before replying?

I'm trying, I'm trying.  

-- Gaby

Re: New gcc 4.0.0 warnings seem spurious

[Vincent Lefevre]

On 2005-04-27 17:30:25 +0200, Gabriel Dos Reis wrote:
> Vincent Lefevre <vincent+gcc@vinc17.org> writes:
> 
> | On 2005-04-27 15:30:39 +0200, Gabriel Dos Reis wrote:
> | > Vincent Lefevre <vincent+gcc@vinc17.org> writes:
> | > 
> | > [...]
> | > 
> | > | >  > But if they are never modified, they evaluate to
> | > | >  > constants, right?
> | > | >  > 
> | > | >  > The fact that they are not considered as constant
> | > | >  > expressions, is it due to the fact that the environment
> | > | >  > is allowed to modify them?
> | > | > 
> | > | > It's due to what the C standard says. A const variable in C
> | > | > isn't a constant, it's just a read-only variable.
> | > | 
> | > | 1+1 isn't a constant either
> | > 
> | > It is an integer constant expression, and its evaluation yields a
> | > constant (see 6.6).  Can you explain why you believe that is false?
> | 
> | I never said that it was false.
> 
> Ah, then what exactly is your point?

That a constant expression isn't necessarily a constant (6.4.4).
So, if one says that some expression isn't a constant, it doesn't
necessarily mean that it isn't a constant expression.

Example: the expression 1+1 is not a constant, but it evaluates to
a constant (2) and it is a constant expression.

So, the only fact that a const variable is not a constant does not
imply that it is not a constant expression, and my questions above
have not been answered.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

RE: New gcc 4.0.0 warnings seem spurious

[Dave Korn]

----Original Message----
>From: Vincent Lefevre
>Sent: 27 April 2005 15:47


> Example: the expression 1+1 is not a constant, 


  OK then, let's see you assign a different value to it!

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: New gcc 4.0.0 warnings seem spurious

[Gabriel Dos Reis]

Vincent Lefevre <vincent+gcc@vinc17.org> writes:

| On 2005-04-27 17:30:25 +0200, Gabriel Dos Reis wrote:
| > Vincent Lefevre <vincent+gcc@vinc17.org> writes:
| > 
| > | On 2005-04-27 15:30:39 +0200, Gabriel Dos Reis wrote:
| > | > Vincent Lefevre <vincent+gcc@vinc17.org> writes:
| > | > 
| > | > [...]
| > | > 
| > | > | >  > But if they are never modified, they evaluate to
| > | > | >  > constants, right?
| > | > | >  > 
| > | > | >  > The fact that they are not considered as constant
| > | > | >  > expressions, is it due to the fact that the environment
| > | > | >  > is allowed to modify them?
| > | > | > 
| > | > | > It's due to what the C standard says. A const variable in C
| > | > | > isn't a constant, it's just a read-only variable.
| > | > | 
| > | > | 1+1 isn't a constant either
| > | > 
| > | > It is an integer constant expression, and its evaluation yields a
| > | > constant (see 6.6).  Can you explain why you believe that is false?
| > | 
| > | I never said that it was false.
| > 
| > Ah, then what exactly is your point?
| 
| That a constant expression isn't necessarily a constant (6.4.4).
| So, if one says that some expression isn't a constant, it doesn't
| necessarily mean that it isn't a constant expression.
| 
| Example: the expression 1+1 is not a constant, but it evaluates to
| a constant (2) and it is a constant expression.
| 
| So, the only fact that a const variable is not a constant does not
| imply that it is not a constant expression, and my questions above
| have not been answered.

It has been answered, but I do not believe you made the effort to
understand the answer.  Now, let me asnwer it one more time.

Read Zack's sentence 

      These are not constants.

from

   http://gcc.gnu.org/ml/gcc/2005-04/msg01436.html

as 

     These (i.e. AAA, etc.) are not constant expressions.

Are you happy now?

-- Gaby

Re: New gcc 4.0.0 warnings seem spurious

[Vincent Lefevre]

On 2005-04-27 18:38:52 +0200, Gabriel Dos Reis wrote:
> It has been answered, but I do not believe you made the effort to
> understand the answer.  Now, let me asnwer it one more time.

The vocabulary is important, and I find the gcc diagnostic (cited
by Bruce) quite confusing. Then it is not surprising that people
complain about bugs.

> Read Zack's sentence 
> 
>       These are not constants.
> 
> from
> 
>    http://gcc.gnu.org/ml/gcc/2005-04/msg01436.html
> 
> as 
> 
>      These (i.e. AAA, etc.) are not constant expressions.
> 
> Are you happy now?

This is better.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: New gcc 4.0.0 warnings seem spurious

[Gabriel Dos Reis]

Vincent Lefevre <vincent+gcc@vinc17.org> writes:

| > Read Zack's sentence 
| > 
| >       These are not constants.
| > 
| > from
| > 
| >    http://gcc.gnu.org/ml/gcc/2005-04/msg01436.html
| > 
| > as 
| > 
| >      These (i.e. AAA, etc.) are not constant expressions.
| > 
| > Are you happy now?
| 
| This is better.

Wow!  Impressive.  

-- Gaby

RE: New gcc 4.0.0 warnings seem spurious

[Dave Korn]

----Original Message----
>From: Vincent Lefevre
>Sent: 27 April 2005 14:59

> On 2005-04-27 15:30:39 +0200, Gabriel Dos Reis wrote:
>> Vincent Lefevre <vincent+gcc@vinc17.org> writes:
>> 
>> [...]
>> 
>>>>  > But if they are never modified, they evaluate to constants, right? 
>>>>  > > The fact that they are not considered as constant expressions,
>>>>  > is it due to the fact that the environment is allowed to modify  >
>>>> them? 
>>>> 
>>>> It's due to what the C standard says.  A const variable in C isn't a
>>>> constant, it's just a read-only variable.
>>> 
>>> 1+1 isn't a constant either
>> 
>> It is an integer constant expression, and its evaluation yields a
>> constant (see 6.6).  Can you explain why you believe that is false?
> 
> I never said that it was false. 

  Yes you did.  You _implied_ it.

  You said "1+1 isn't a constant either".

  Gabriel said that it is a constant, and explained precisely why it is a
constant.

  He then asked you what you thought was false in his explanation.

  He did not claim that you had already said his explanation was false, but,
if you still believe "1+1 isn't a constant either", then you *must* also
believe that Gabi's explanation of why it **IS** a constant is false.

> Could you please read messages before replying?

  It just goes to show that merely reading messages before replying isn't
sufficient either.  You have to *comprehend* them too.

  Vincent, it is time you went and did some background research, rather than
carry on pontificating on subjects on which you are completely misinformed.
You appear to be acting under the belief that you are the only person ever
to correctly understand the C language spec and that everyone who has ever
implemented a C compiler has got it wrong.

  This is unlikely, to say the least.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: New gcc 4.0.0 warnings seem spurious

[Vincent Lefevre]

On 2005-04-27 15:44:15 +0100, Dave Korn wrote:
> ----Original Message----
> >From: Vincent Lefevre
> >Sent: 27 April 2005 14:59
> 
> > On 2005-04-27 15:30:39 +0200, Gabriel Dos Reis wrote:
> >> Vincent Lefevre <vincent+gcc@vinc17.org> writes:
> >> 
> >> [...]
> >> 
> >>>>  > But if they are never modified, they evaluate to constants, right? 
> >>>>  > > The fact that they are not considered as constant expressions,
> >>>>  > is it due to the fact that the environment is allowed to modify  >
> >>>> them? 
> >>>> 
> >>>> It's due to what the C standard says.  A const variable in C isn't a
> >>>> constant, it's just a read-only variable.
> >>> 
> >>> 1+1 isn't a constant either
> >> 
> >> It is an integer constant expression, and its evaluation yields a
> >> constant (see 6.6).  Can you explain why you believe that is false?
> > 
> > I never said that it was false. 
> 
>   Yes you did.  You _implied_ it.

No.

>   You said "1+1 isn't a constant either".

Yes. FYI, here are the constants:

       6.4.4  Constants

       Syntax

       [#1]

               constant:
                       integer-constant
                       floating-constant
                       enumeration-constant
                       character-constant

I cannot see any form for 1+1 here.

>   Gabriel said that it is a constant, and explained precisely why it
> is a constant.

Gabriel said that it evaluates to a constant. And I don't disagree
with him here.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: New gcc 4.0.0 warnings seem spurious

[Gabriel Dos Reis]

Vincent Lefevre <vincent+gcc@vinc17.org> writes:

| > Bruce Lilly <blilly@erols.com> writes:
| > > static const unsigned char AAA = 0x1U;
| > > static const unsigned char BBB = 0x2U;
| > 
| > Again, C does not work the way you think.  These are not constants.
| 
| But if they are never modified, they evaluate to constants, right?

No.

| The fact that they are not considered as constant expressions,
| is it due to the fact that the environment is allowed to modify
| them?

Language restriction -- a difference from C++.

-- Gaby