From: Bernardo Innocenti <bernie@develer.com>
Organization: Develer
To: Philippe Elie <phil.el@wanadoo.fr>
Subject: Re: SPAM[RBL] Re: C99 types VS Linus types
Date: Sun, 6 Jul 2003 19:37:26 +0200
User-Agent: KMail/1.5.9
Cc: linux-kernel@vger.kernel.org, Richard Henderson <rth@twiddle.net>
References: <200307060703.58533.bernie@develer.com> <3F0814B1.1000401@wanadoo.fr>
In-Reply-To: <3F0814B1.1000401@wanadoo.fr>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <200307061937.26519.bernie@develer.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1425
Lines: 44

On Sunday 06 July 2003 14:23, Philippe Elie wrote:

 > alpha user space .h define uint64_t as unsigned long,
 > include/asm-alpha/types.h defines it as unsigned long long.

 Why is that? Isn't uint64_t supposed to be _always_ a 64bit
unsigned integer? Either the kernel or the user space might
be doing the wrong thing...

 I've Cc'd the Alpha mantainer to make him aware of this
problem.

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

 This is ugly, but there is no way around it. No matter what
typedefs you're using, C99 or not, printf size specifiers are
always bound to plain C types, whose size varies from
platform to platform.

 > surely vim allow to define your own set of type ?

 Yeah, but not if you're lazy ;-)

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Please don't send Word attachments - http://www.gnu.org/philosophy/no-word-attachments.html


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