Re: 0xdeadbeef vs 0xdeadbeefL
From: Ray Lee (ray-lk_at_madrabbit.org)
Date: 07/07/04
- Previous message: Redeeman: "Re: [PATCH] fix tcp_default_win_scale."
- In reply to: Alexandre Oliva: "Re: 0xdeadbeef vs 0xdeadbeefL"
- Next in thread: viro_at_parcelfarce.linux.theplanet.co.uk: "Re: 0xdeadbeef vs 0xdeadbeefL"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
To: Alexandre Oliva <aoliva@redhat.com> Date: Tue, 06 Jul 2004 23:08:40 -0700
On Tue, 2004-07-06 at 22:55, Alexandre Oliva wrote:
> On Jul 6, 2004, Ray Lee <ray-lk@madrabbit.org> wrote:
>
> > Which means 0xdeadbeef is a perfectly valid literal for an unsigned int.
>
> Assuming ints are 32-bits wide. They don't have to be.
In which case the rest of that line that read:
it has the first possible of these types ["in which its value
can be represented" -- from omitted]: int, unsigned int, long
int, unsigned long int.
...kicks in.
> or they could be wider than 32 bits, in which case the constant will
> be signed int instead of unsigned int.
Read that line again. This would only happen if the platform has no
unsigned 32 bit integer whatsoever. If you can point out one of those to
me that Linux runs on, then I'll concede the point. On any other
platform, the constant oct/hex int promotion rules will walk it up to a
32-bit unsigned before it hits the larger types.
Ray
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Previous message: Redeeman: "Re: [PATCH] fix tcp_default_win_scale."
- In reply to: Alexandre Oliva: "Re: 0xdeadbeef vs 0xdeadbeefL"
- Next in thread: viro_at_parcelfarce.linux.theplanet.co.uk: "Re: 0xdeadbeef vs 0xdeadbeefL"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
