Message-ID: <3F0814B1.1000401@wanadoo.fr>
Date: Sun, 06 Jul 2003 12:23:13 +0000
From: Philippe Elie <phil.el@wanadoo.fr>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605
MIME-Version: 1.0
To: Bernardo Innocenti <bernie@develer.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: C99 types VS Linus types
References: <200307060703.58533.bernie@develer.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1345
Lines: 42

Bernardo Innocenti wrote:
> Hello,
hi,

> Since C99, the C language has acquired a standard set of machine
> independent types that can be used for machine independent
> fixed-width declarations.
> 
> Getting rid of all non-ISO types from kernel code could be a
> desiderable long-term goal. Besides the inexplicable goodness
> of standards compliance, my favourite argument is that not
> depending on custom definitions makes copying code from/to
> other projects a little easier.

alpha user space .h define uint64_t as unsigned long,
include/asm-alpha/types.h defines it as unsigned long long.
Using a different definition (if it's possible) will be
confusing. Using the same definition as user space means
than code like:

uint64 t u;
printk("%lu", u);

will not compile on alpha. This problem is solved in C99
by using PRI_xxx format specifier macro, I'm not a great
fan of this idea.

> Ok, "int32_t" is a little more typing than "s32_t", but in
> exchange you get it syntax hilighted in vim like built-in
> types ;-)

surely vim allow to define your own set of type ?

regards,
Philippe Elie


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