public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Albert Cahalan <albert@users.sf.net>
To: matthias.andree@gmx.de, linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: C99 types VS Linus types
Date: 07 Jul 2003 08:01:45 -0400	[thread overview]
Message-ID: <1057579305.747.79.camel@cube> (raw)

Matthias Andree writes:
> On Sun, 06 Jul 2003, Albert Cahalan wrote:

>> 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.
>
> What if unsigned long long is 96 bit? or 128?

I think you're trolling, but just in case not...

The days of non-power-of-two word sizes are
gone for normal computing. Sign-magnitude and
ones-compliment are dead too. Float is IEEE
format, possibly skipping a few costly features.
Nobody is going to go back to the old way.

It's too bad the C99 committee didn't have the
guts to make this official.

As for 128-bit...

>> It ought to be at least 40 years
>> before 128-bit types begin to matter.
>
> Yup, and 8-Bit CPU and 640 kB RAM ought to be enough for...
>
> nevermind.

There's a logrithmic/exponential thing going on.
Measuring bits isn't like measuring kB. It's log(kB),
which interacts with Moore's law to give a plain
linear need for bits. It took about 20 years to eat
through the extra bits we got with 32-bit CPUs. Now
we have twice as many bits to eat through. So that's
40 years right there. People will make do for much
longer though; notice that 8-bit was never comfy
while 32-bit was.

>> 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);
>
> Speaking of shifting forward to standards:
>
> unsigned char foo = 42;
> char bar[42];
> sprintf(bar, "%ju", (uintmax_t)foo); // see IEEE Std 1003.1-2001
>
> If that's too ugly, write your own [u]intmax_t-to-char[]
> converter, then only the stack is nasty if uintmax_t is 128
> bits wide and you're printing an array uint8_t. :-P

Yes, that is too ugly. It's idealistic code.
Readability matters more than worrying about
something which won't happen for over 40 years,
and won't cause Y2K-style problems even then.

If I live that long, I'll need employment anyway.

Perfection is the enemy of good. In practice,
there is a difference between theory and practice.
Etc.



             reply	other threads:[~2003-07-07 11:55 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-07 12:01 Albert Cahalan [this message]
2003-07-07 12:22 ` C99 types VS Linus types Matthias Andree
2003-07-07 12:24 ` Alan Cox
  -- strict thread matches above, loose matches on Subject: below --
2003-07-06 22:18 Albert Cahalan
2003-07-07  1:59 ` Matthias Andree
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=1057579305.747.79.camel@cube \
    --to=albert@users.sf.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthias.andree@gmx.de \
    /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