C99 types VS Linus types

C99 types VS Linus types

[Bernardo Innocenti]

Hello,

before a standard was set, every single OS had to come up with its
own fancy fixed-size type definitions such as DWORD, ULONG, u32,
CARD32, u_int32_t and so on.

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.

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 ;-)

I suggest a soft approach: trying to use C99 types as much
as possible for new code and only converting old code to
C99 when it's not too much trouble.

I hope it doesn't turn into an endless flame war... This is
just a polite suggestion.

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

Re: C99 types VS Linus types

[Philippe Elie]

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

Re: SPAM[RBL] Re: C99 types VS Linus types

[Bernardo Innocenti]

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

Re: SPAM[RBL] Re: C99 types VS Linus types

[Vojtech Pavlik]

On Sun, Jul 06, 2003 at 07:37:26PM +0200, Bernardo Innocenti wrote:

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

I suppose both an 'unsigned long' and 'unsigned long long' are 64-bit
entities on the Alpha (which is a 64-bit architecture).

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: SPAM[RBL] Re: C99 types VS Linus types

[Jamie Lokier]

Bernardo Innocenti wrote:
> 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...

uint64_t is always a 64-bit type, and in the case given the compiler
emits a warning but the code runs ok.

The problem is that "64-bit long" and "64-bit long long" are different
types with the same representation.  Which means they are mostly
interchangeable, with occasional C weirdness.

-- Jamie