Re: Use of C99 int types

[Kyle Moffett <mrmacman_g4@mac.com>]

On Apr 05, 2005, at 05:23, Renate Meijer wrote:
> > uint8/16/32/64, on the other hand, are specific bit-sizes, which
> > may not be as fast or correct as a simple size_t.
>
> Using specific widths may yield benefits on one platform, whilst
> proving a real bottleneck when porting something to another. A
> potential of problems easily avoided by using plain-vanilla
> integers.

The point of specific-width integers is to preserve a specific
binary format, such as a filesystem on-disk data structure, or a
kernel-userspace ABI, etc.  If you just need a number, use a
different type.

> Strictly speaking, a definition starting with a double
> underscore is reserved for use by the compiler and associated
> libs

Well, _strictly_speaking_, it's "implementation defined", where the
"implementation" includes the kernel (due to the syscall interface).

> this such a declaration would invade implementation namespace.
> The compilers implementation, that is.

But the C library is implicitly dependent on the kernel headers for
a wide variety of datatypes.

> In this case, the boundary is a bit vague, i see that, since a lot
> of header definitions also reside in the /usr/include hierarchy.

Some of which are produced by kernel sources: /usr/include/linux,
/usr/include/asm, etc.

> I think it would be usefull to at least *agree* on a standard type
> for 8/16/32/64-bit integer types. What I see now as a result of
> grepping for 'uint32' is a lot more confusing than stdint.h

Well, Linus has supported that there is no standard, except where
ABI is concerned, there we must use __u32 so that it does not clash
with libc or user programs.

> Especially the types with leading underscores look cool, but in
> reality may cause a conflict with compiler internals and should only
> be used when defining compiler libraries.

It's "implementation" (kernel+libc+gcc) defined.  It just means that
gcc, the kernel, and libc have to be much more careful not to tread
on each others toes.

> The '__' have explicitly been put in by ISO in order to avoid
> conflicts between user-code and the standard libraries,

The "standard libraries" includes the syscall interface here.  If
the kernel types could not be prefixed with __, then what _should_
we prefix them with?

> Furthermore, I think it's wise to convince the community that if
> not needed, integers should not be specified by any specific width.

That doesn't work for an ABI.  If you switch compilers (or from 32-bit
to 64-bit like from x86 to x86-64, you _must_ be able to specify
certain widths for all the ABI numbers to preserve compatibility.

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r  
!y?(-)
------END GEEK CODE BLOCK------


-
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/