All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bernd Petrovitsch <bernd@petrovitsch.priv.at>
To: Julia Lawall <julia@diku.dk>
Cc: Dan Carpenter <error27@gmail.com>,
	kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: bug list: assigning negative values to unsigned variables
Date: Wed, 27 Jan 2010 14:12:49 +0000	[thread overview]
Message-ID: <1264601569.10795.131.camel@localhost> (raw)
In-Reply-To: <Pine.LNX.4.64.1001271329460.20256@ask.diku.dk>

On Mit, 2010-01-27 at 13:30 +0100, Julia Lawall wrote:
> On Wed, 27 Jan 2010, Bernd Petrovitsch wrote:
> > On Mit, 2010-01-27 at 11:57 +0100, Julia Lawall wrote:
> > > On Wed, 27 Jan 2010, Dan Carpenter wrote:
> > > 
> > > > Fixing the places which assign negative values to unsigned variables is a good janitor task.
> > > 
> > > I had the impression that assignment to -1 was done sometimes as a 
> > > portable way to initialize the variable to 0xffff (for any number of f's).  
Hmm, perhaps some experienced language lawyer can comment on the
"portable".
> > > So perhaps it is not so trivial to fix.
> > Any particular reason that ~0U, ~0UL, and ~0ULL shouldn't do the same
> > (without relying on conversion from signed to unsigned)?
> 
> Then the constant specifies the type?
Yes. And it is necessary as "~0U" assigned to a "unsigned long long int"
won't give "~0ULL".
Otherwise "0" would be a signed int and from then on (starting with
"~0") we are in the C hell of type promotion/conversion from signed to
unsigned and/or back - at least in theory.

	Bernd
-- 
Bernd Petrovitsch                  Email : bernd@petrovitsch.priv.at
                     LUGA : http://www.luga.at


WARNING: multiple messages have this Message-ID (diff)
From: Bernd Petrovitsch <bernd@petrovitsch.priv.at>
To: Julia Lawall <julia@diku.dk>
Cc: Dan Carpenter <error27@gmail.com>,
	kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: bug list: assigning negative values to unsigned variables
Date: Wed, 27 Jan 2010 15:12:49 +0100	[thread overview]
Message-ID: <1264601569.10795.131.camel@localhost> (raw)
In-Reply-To: <Pine.LNX.4.64.1001271329460.20256@ask.diku.dk>

On Mit, 2010-01-27 at 13:30 +0100, Julia Lawall wrote:
> On Wed, 27 Jan 2010, Bernd Petrovitsch wrote:
> > On Mit, 2010-01-27 at 11:57 +0100, Julia Lawall wrote:
> > > On Wed, 27 Jan 2010, Dan Carpenter wrote:
> > > 
> > > > Fixing the places which assign negative values to unsigned variables is a good janitor task.
> > > 
> > > I had the impression that assignment to -1 was done sometimes as a 
> > > portable way to initialize the variable to 0xffff (for any number of f's).  
Hmm, perhaps some experienced language lawyer can comment on the
"portable".
> > > So perhaps it is not so trivial to fix.
> > Any particular reason that ~0U, ~0UL, and ~0ULL shouldn't do the same
> > (without relying on conversion from signed to unsigned)?
> 
> Then the constant specifies the type?
Yes. And it is necessary as "~0U" assigned to a "unsigned long long int"
won't give "~0ULL".
Otherwise "0" would be a signed int and from then on (starting with
"~0") we are in the C hell of type promotion/conversion from signed to
unsigned and/or back - at least in theory.

	Bernd
-- 
Bernd Petrovitsch                  Email : bernd@petrovitsch.priv.at
                     LUGA : http://www.luga.at


  reply	other threads:[~2010-01-27 14:12 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-27 10:40 bug list: assigning negative values to unsigned variables Dan Carpenter
2010-01-27 10:40 ` Dan Carpenter
2010-01-27 10:57 ` Julia Lawall
2010-01-27 10:57   ` Julia Lawall
2010-01-27 11:09   ` Bernd Petrovitsch
2010-01-27 11:09     ` Bernd Petrovitsch
2010-01-27 12:30     ` Julia Lawall
2010-01-27 12:30       ` Julia Lawall
2010-01-27 14:12       ` Bernd Petrovitsch [this message]
2010-01-27 14:12         ` Bernd Petrovitsch
2010-01-27 14:44         ` Al Viro
2010-01-27 11:13   ` Dan Carpenter
2010-01-27 11:13     ` Dan Carpenter

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=1264601569.10795.131.camel@localhost \
    --to=bernd@petrovitsch.priv.at \
    --cc=error27@gmail.com \
    --cc=julia@diku.dk \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.