All of lore.kernel.org
 help / color / mirror / Atom feed
From: Albert Cahalan <albert@users.sf.net>
To: bernie@develer.com, vojtech@suse.cz,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: C99 types VS Linus types
Date: 06 Jul 2003 18:18:26 -0400	[thread overview]
Message-ID: <1057529906.749.41.camel@cube> (raw)

Vojtech Pavlik writes:
> On Sun, Jul 06, 2003 at 07:37:26PM +0200, Bernardo Innocenti wrote:
>> On Sunday 06 July 2003 14:23, Philippe Elie wrote:

>>> alpha user space .h define uint64_t as unsigned long,
>>> include/asm-alpha/types.h defines it as unsigned long long.
>>
>> Why is that? Isn't uint64_t supposed to be _always_ a 64bit
>> unsigned integer? Either the kernel or the user space might
>> be doing the wrong thing...
>>
>>  I've Cc'd the Alpha mantainer to make him aware of this
>> problem.
>
> I suppose both an 'unsigned long' and 'unsigned long long'
> are 64-bit entities on the Alpha (which is a 64-bit
> architecture).

Sure, both are "correct", but there would be a lot less
pain and suffering in the world if "unsigned long long"
would be used for 64-bit. It ought to be at least 40 years
before 128-bit types begin to matter. In the Linux world,
we can consider "long long" to be 64-bit, "int" to be
32-bit, and "long" to be the same size as a pointer.

Then we can ditch the nasty casts:
sprintf(foo, "%llu", (unsigned long long)bar);

This leaves only Win64, Win16, DOS, and ELKS out in
the cold. Like we should care for kernel & glibc!



             reply	other threads:[~2003-07-06 22:12 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-06 22:18 Albert Cahalan [this message]
2003-07-07  1:59 ` C99 types VS Linus types Matthias Andree
  -- strict thread matches above, loose matches on Subject: below --
2003-07-07 12:01 Albert Cahalan
2003-07-07 12:22 ` Matthias Andree
2003-07-07 12:24 ` Alan Cox
2003-07-06  5:03 Bernardo Innocenti
2003-07-06 12:23 ` Philippe Elie

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=1057529906.749.41.camel@cube \
    --to=albert@users.sf.net \
    --cc=bernie@develer.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vojtech@suse.cz \
    /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.