From: Andrew Haley <aph@redhat.com>
To: Vincent Lefevre <vincent+gcc@vinc17.org>
Cc: gcc@gcc.gnu.org
Subject: Re: New gcc 4.0.0 warnings seem spurious
Date: Wed, 27 Apr 2005 11:26:00 -0000 [thread overview]
Message-ID: <17007.27519.360256.836158@cuddles.cambridge.redhat.com> (raw)
In-Reply-To: <20050427100423.GI3983@ay.vinc17.org>
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.
next prev parent reply other threads:[~2005-04-27 10:38 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-26 15:10 Bruce Lilly
2005-04-26 15:59 ` Joseph S. Myers
2005-04-26 21:43 ` Bruce Lilly
2005-04-26 22:02 ` Zack Weinberg
2005-04-27 10:38 ` Vincent Lefevre
2005-04-27 11:16 ` Zack Weinberg
2005-04-27 11:30 ` Vincent Lefevre
2005-04-27 11:55 ` Andrew Haley
2005-04-27 12:07 ` Vincent Lefevre
2005-04-27 12:48 ` Gabriel Dos Reis
2005-04-27 13:59 ` Vincent Lefevre
2005-04-27 14:18 ` Gabriel Dos Reis
2005-04-27 12:18 ` Gabriel Dos Reis
2005-04-27 14:16 ` Vincent Lefevre
2005-04-27 12:28 ` Neil Booth
2005-04-27 21:35 ` Mike Stump
2005-04-28 16:24 ` Vincent Lefevre
2005-04-27 12:15 ` Gabriel Dos Reis
2005-04-27 11:26 ` Andrew Haley [this message]
2005-04-27 11:34 ` Vincent Lefevre
2005-04-27 11:56 ` Andrew Haley
2005-04-27 12:09 ` Vincent Lefevre
2005-04-27 13:47 ` Gabriel Dos Reis
2005-04-27 14:14 ` Vincent Lefevre
2005-04-27 14:20 ` Gabriel Dos Reis
2005-04-27 12:32 ` Gabriel Dos Reis
2005-04-27 14:11 ` Vincent Lefevre
2005-04-27 14:18 ` Gabriel Dos Reis
2005-04-27 15:05 ` Vincent Lefevre
2005-04-27 15:15 ` Dave Korn
2005-04-27 15:32 ` Gabriel Dos Reis
2005-04-27 16:24 ` Vincent Lefevre
2005-04-27 16:44 ` Gabriel Dos Reis
2005-04-27 15:00 ` Dave Korn
2005-04-27 15:29 ` Vincent Lefevre
2005-04-27 12:14 ` Gabriel Dos Reis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=17007.27519.360256.836158@cuddles.cambridge.redhat.com \
--to=aph@redhat.com \
--cc=gcc@gcc.gnu.org \
--cc=vincent+gcc@vinc17.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).