All of lore.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 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.