Newsgroups: fa.linux.kernel
From: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Subject: Re: Use of C99 int types
Original-Message-ID: <20050403230551.GX8859@parcelfarce.linux.theplanet.co.uk>
Date: Sun, 3 Apr 2005 23:08:00 GMT
Message-ID: <fa.nrrgesr.1r7812l@ifi.uio.no>

On Mon, Apr 04, 2005 at 12:48:04AM +0200, Dag Arne Osvik wrote:
> unsigned long happens to coincide with uint_fast32_t for x86 and x86-64,
> but there's no guarantee that it will on other architectures.  And, at
> least in theory, long may even provide less than 32 bits.

To port on such platform we'd have to do a lot of rewriting - so much that
the impact of this issue will be lost in noise.

Look, it's very simple:
	* too many people blindly assume that all world is 32bit l-e.
	* too many of those who try to do portable code have very little
idea of what that means - see the drivers that try and mix e.g. size_t with
int, etc.
	* stdint is not widely understood, to put it mildly.
	* ...fast... types have very unfortunate names - these are guaranteed
to create a lot of confusion.
	* pretty much everything in the kernel assumes that
4 = sizeof(int) <=
sizeof(long) = sizeof(pointer) = sizeof(size_t) = sizeof(ptrdiff_t) <=
sizeof(long long) = 8
and any platform that doesn't satisfy the above will require very serious
work on porting anyway.

Newsgroups: fa.linux.kernel
From: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Subject: Re: [PATCH] cx88: fix printk arg. type
Original-Message-ID: <20041117175811.GE26051@parcelfarce.linux.theplanet.co.uk>
Date: Wed, 17 Nov 2004 18:56:13 GMT
Message-ID: <fa.n3cjciq.1jhcpje@ifi.uio.no>

On Wed, Nov 17, 2004 at 06:25:19PM +0100, Gerd Knorr wrote:
> > -		dprintk(0, "ERROR: Firmware size mismatch (have %ld, expected %d)\n",
> > +		dprintk(0, "ERROR: Firmware size mismatch (have %Zd, expected %d)\n",
>
> Thanks, merged to cvs.  I like that 'Z'.  Or is that just a linux-kernel
> printk specific thingy?  Or is this standardized somewhere?  So I could
> use that in userspace code as well maybe?

'Z' is an obsolete equivalent of standard 'z'.  That one is portable and it
is, indeed, available in userland (libc6 and anything C99-compliant).  To
quote the manpage:

       z      A  following  integer  conversion  corresponds  to  a  size_t or
              ssize_t argument. (Linux libc5 has Z with  this  meaning.  Don't
              use it.)

       t      A  following integer conversion corresponds to a ptrdiff_t argu-
              ment.

Please, do s/Zd/zd/.

One more thing: folks, please stop using crap like "%08x", (int)pointer.
It's not only non-portable (consider 64bit boxen), it's extra work for
no good reason.  "%p" is standard and will do the right thing with less
PITA.

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: [PATCH 01/24] types: create <asm-generic/int-*.h>
Date: Fri, 25 Apr 2008 18:37:33 UTC
Message-ID: <fa.yKPse4qhbGR5rnbCToA2gOxQAyk@ifi.uio.no>

On Fri, 25 Apr 2008, Jan Engelhardt wrote:
>
> long long is 64 bits on both 32 and 64, is not it?
> If so, the split between 32 and 64 should not be necessary.

They may be the same size, but there are still pure C-level _type_
differences that the compiler will warn about.

This is the same issue as a 32-bit type on x86-32: is it an "int" or a
"long"? From a pure size perspective it shouldn't matter, but if you pass
a pointer to it, or use it in a "printf()", it matters a whole lot,
because the compiler will complain if you use the wrong version.

So on some 32-bit architectures, "size_t" is "unsigned int", on others it
is "unsigned long", and you have to get it right in order to avoid
complaints.

The exact same thing is true about "long" vs "long long" on 64-bit
architectures. They may have the same size, but they don't have the same
type.

		Linus

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: [PATCH 01/24] types: create <asm-generic/int-*.h>
Date: Fri, 25 Apr 2008 19:12:02 UTC
Message-ID: <fa.SsTou/BYFdtEQaktf8bkW4s/fLA@ifi.uio.no>

On Fri, 25 Apr 2008, Matthew Wilcox wrote:
>
> So ... given all this, why do we define s64 to be 'long' on some
> architectures and 'long long' on others?

Historical reasons, mainly. Once we start using one type for things like
loff_t, it ends up getting encoded in user header files, and we're then
basically forced to continue to use that particular type. Some of them end
literally being embedded in the compiler itself (ie __builtin_size_t etc
end up being known by compiler built-ins).

But yes, we could probably try to standardize the internal kernel s64/u64
types that don't end up spreading anywhere else.

Of course, part of the worry is probably that people thought that maybe
"long long" would some day be 128-bit on a 64-bit architecture.

			Linus

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: [PATCH 01/24] types: create <asm-generic/int-*.h>
Date: Fri, 25 Apr 2008 19:45:32 UTC
Message-ID: <fa.7hGxIab+UMIXzL9DBb7APOkxsuk@ifi.uio.no>

On Fri, 25 Apr 2008, H. Peter Anvin wrote:
>
> I have to admit to liking the Windows extension %I64u for this kind of stuff.
> Unfortunately gcc/glibc decided to use I for internationalized digits instead
> :(

The sad part is that this is purely a gcc thing. We could easily do the
right thing in the kernel vsnprintf stuff, but then we'd have to drop the
nice format warnings from gcc ;(

		Linus