On Apr 6, 2005, at 11:11 PM, Kyle Moffett wrote:
On Apr 06, 2005, at 07:41, Renate Meijer wrote:
On Apr 6, 2005, at 12:11 AM, Kyle Moffett wrote:
Please don't remove Linux-Kernel from the CC, I think this is an
important discussion.
GAAH!!! Read my lips!!! Quit removing Linux-Kernel from the CC!!!
On Apr 6, 2005, at 11:11 PM, Kyle Moffett wrote:
On Apr 06, 2005, at 07:41, Renate Meijer wrote:
On Apr 6, 2005, at 12:11 AM, Kyle Moffett wrote:
Please don't remove Linux-Kernel from the CC, I think this is an
important discussion.
GAAH!!! Read my lips!!! Quit removing Linux-Kernel from the CC!!!
On Apr 06, 2005, at 07:41, Renate Meijer wrote:
On Apr 6, 2005, at 12:11 AM, Kyle Moffett wrote:
Please don't remove Linux-Kernel from the CC, I think this is an
important discussion.
GAAH!!! Read my lips!!! Quit removing Linux-Kernel from the CC!!!
As I see it, there are a number of issues
- Use
On Apr 06, 2005, at 07:41, Renate Meijer wrote:
On Apr 6, 2005, at 12:11 AM, Kyle Moffett wrote:
Please don't remove Linux-Kernel from the CC, I think this is an
important discussion.
GAAH!!! Read my lips!!! Quit removing Linux-Kernel from the CC!!!
As I see it, there are a number of issues
- Use
Please don't remove Linux-Kernel from the CC, I think this is an
important discussion.
On Apr 05, 2005, at 15:17, Renate Meijer wrote:
Strictly speaking, a definition starting with a double
underscore is reserved for use by the compiler and associated
libs
Well, _strictly_speaking_, it's
On Apr 05, 2005, at 08:18, Richard B. Johnson wrote:
One cannot just use 'int' or 'long', in particular when interfacing
with an operating system. For example, look at the socket interface
code. Parameters are put into an array of longs and a pointer to
this array is passed to the socket
On Mon, 4 Apr 2005, Kyle Moffett wrote:
On Apr 04, 2005, at 17:25, Richard B. Johnson wrote:
I don't find stdint.h in the kernel source (up to 2.6.11). Is this
going to be a new addition?
Uhh, no. stdint.h is part of glibc, not the kernel.
It would be very helpful to start using the
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
On Apr 4, 2005, at 11:49 PM, Kyle Moffett wrote:
On Apr 04, 2005, at 17:25, Richard B. Johnson wrote:
I don't find stdint.h in the kernel source (up to 2.6.11). Is this
going to be a new addition?
Uhh, no. stdint.h is part of glibc, not the kernel.
It would be very helpful to start using the
On Apr 4, 2005, at 10:57 PM, Al Viro wrote:
On Mon, Apr 04, 2005 at 10:30:52PM +0200, Renate Meijer wrote:
When used improperly. The #define Al Viro objected to, is
objectionable. It's highly
misleading, as Mr. Viro pointed out. I fail to see where he made
comments on stdint.h
as such.
Comments on
On Apr 05, 2005, at 08:18, Richard B. Johnson wrote:
One cannot just use 'int' or 'long', in particular when interfacing
with an operating system. For example, look at the socket interface
code. Parameters are put into an array of longs and a pointer to
this array is passed to the socket
Please don't remove Linux-Kernel from the CC, I think this is an
important discussion.
On Apr 05, 2005, at 15:17, Renate Meijer wrote:
Strictly speaking, a definition starting with a double
underscore is reserved for use by the compiler and associated
libs
Well, _strictly_speaking_, it's
On Apr 4, 2005, at 10:57 PM, Al Viro wrote:
On Mon, Apr 04, 2005 at 10:30:52PM +0200, Renate Meijer wrote:
When used improperly. The #define Al Viro objected to, is
objectionable. It's highly
misleading, as Mr. Viro pointed out. I fail to see where he made
comments on stdint.h
as such.
Comments on
On Apr 4, 2005, at 11:49 PM, Kyle Moffett wrote:
On Apr 04, 2005, at 17:25, Richard B. Johnson wrote:
I don't find stdint.h in the kernel source (up to 2.6.11). Is this
going to be a new addition?
Uhh, no. stdint.h is part of glibc, not the kernel.
It would be very helpful to start using the
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
On Mon, 4 Apr 2005, Kyle Moffett wrote:
On Apr 04, 2005, at 17:25, Richard B. Johnson wrote:
I don't find stdint.h in the kernel source (up to 2.6.11). Is this
going to be a new addition?
Uhh, no. stdint.h is part of glibc, not the kernel.
It would be very helpful to start using the
On Apr 04, 2005, at 17:25, Richard B. Johnson wrote:
I don't find stdint.h in the kernel source (up to 2.6.11). Is this
going to be a new addition?
Uhh, no. stdint.h is part of glibc, not the kernel.
It would be very helpful to start using the uint(8,16,32,64)_t types
because they are
On Mon, 4 Apr 2005, Al Viro wrote:
On Mon, Apr 04, 2005 at 10:30:52PM +0200, Renate Meijer wrote:
When used improperly. The #define Al Viro objected to, is
objectionable. It's highly
misleading, as Mr. Viro pointed out. I fail to see where he made
comments on stdint.h
as such.
Comments on stdint.h
On Mon, Apr 04, 2005 at 10:30:52PM +0200, Renate Meijer wrote:
> When used improperly. The #define Al Viro objected to, is
> objectionable. It's highly
> misleading, as Mr. Viro pointed out. I fail to see where he made
> comments on stdint.h
> as such.
Comments on stdint.h are very simple:
On Apr 4, 2005, at 12:50 PM, Dag Arne Osvik wrote:
Renate Meijer wrote:
On Apr 4, 2005, at 12:08 AM, Kyle Moffett wrote:
On Apr 03, 2005, at 16:25, Kenneth Johansson wrote:
But is this not exactly what Dag Arne Osvik was trying to do ??
uint_fast32_t means that we want at least 32 bits but it's OK
Renate Meijer wrote:
On Apr 4, 2005, at 12:08 AM, Kyle Moffett wrote:
On Apr 03, 2005, at 16:25, Kenneth Johansson wrote:
But is this not exactly what Dag Arne Osvik was trying to do ??
uint_fast32_t means that we want at least 32 bits but it's OK with
more if that happens to be faster on this
On Apr 4, 2005, at 12:08 AM, Kyle Moffett wrote:
On Apr 03, 2005, at 16:25, Kenneth Johansson wrote:
But is this not exactly what Dag Arne Osvik was trying to do ??
uint_fast32_t means that we want at least 32 bits but it's OK with
more if that happens to be faster on this particular architecture.
Herbert Xu wrote:
Dag Arne Osvik <[EMAIL PROTECTED]> wrote:
... and with such name 99% will assume (at least at the first reading)
that it _is_ 32bits. We have more than enough portability bugs as it
is, no need to invite more by bad names.
Agreed. The way I see it there are two
Herbert Xu wrote:
Dag Arne Osvik [EMAIL PROTECTED] wrote:
... and with such name 99% will assume (at least at the first reading)
that it _is_ 32bits. We have more than enough portability bugs as it
is, no need to invite more by bad names.
Agreed. The way I see it there are two
Renate Meijer wrote:
On Apr 4, 2005, at 12:08 AM, Kyle Moffett wrote:
On Apr 03, 2005, at 16:25, Kenneth Johansson wrote:
But is this not exactly what Dag Arne Osvik was trying to do ??
uint_fast32_t means that we want at least 32 bits but it's OK with
more if that happens to be faster on this
On Apr 4, 2005, at 12:50 PM, Dag Arne Osvik wrote:
Renate Meijer wrote:
On Apr 4, 2005, at 12:08 AM, Kyle Moffett wrote:
On Apr 03, 2005, at 16:25, Kenneth Johansson wrote:
But is this not exactly what Dag Arne Osvik was trying to do ??
uint_fast32_t means that we want at least 32 bits but it's OK
On Mon, Apr 04, 2005 at 10:30:52PM +0200, Renate Meijer wrote:
When used improperly. The #define Al Viro objected to, is
objectionable. It's highly
misleading, as Mr. Viro pointed out. I fail to see where he made
comments on stdint.h
as such.
Comments on stdint.h are very simple:
On Mon, 4 Apr 2005, Al Viro wrote:
On Mon, Apr 04, 2005 at 10:30:52PM +0200, Renate Meijer wrote:
When used improperly. The #define Al Viro objected to, is
objectionable. It's highly
misleading, as Mr. Viro pointed out. I fail to see where he made
comments on stdint.h
as such.
Comments on stdint.h
On Apr 04, 2005, at 17:25, Richard B. Johnson wrote:
I don't find stdint.h in the kernel source (up to 2.6.11). Is this
going to be a new addition?
Uhh, no. stdint.h is part of glibc, not the kernel.
It would be very helpful to start using the uint(8,16,32,64)_t types
because they are
Dag Arne Osvik <[EMAIL PROTECTED]> wrote:
>
>>... and with such name 99% will assume (at least at the first reading)
>>that it _is_ 32bits. We have more than enough portability bugs as it
>>is, no need to invite more by bad names.
>
> Agreed. The way I see it there are two reasonable options.
On Mon, Apr 04, 2005 at 12:48:04AM +0200, Dag Arne Osvik wrote:
> Andreas Schwab wrote:
>
> >Dag Arne Osvik <[EMAIL PROTECTED]> writes:
> >
> >
> >
> >>Yes, but wouldn't it be much better to avoid code like the following,
> >>which may also be wrong (in terms of speed)?
> >>
> >>#ifdef
Grzegorz Kulewski wrote:
On Mon, 4 Apr 2005, Dag Arne Osvik wrote:
(...) And, at least in theory, long may even provide less than 32 bits.
Are you sure?
My copy of famous C book by B. W. Kernighan and D. Ritchie says that
sizeof(short) <= sizeof(int) <= sizeof(long)
and
sizeof(short) >= 16,
On Mon, 4 Apr 2005, Dag Arne Osvik wrote:
(...) And, at least in
theory, long may even provide less than 32 bits.
Are you sure?
My copy of famous C book by B. W. Kernighan and D. Ritchie says that
sizeof(short) <= sizeof(int) <= sizeof(long)
and
sizeof(short) >= 16,
sizeof(int) >= 16,
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
Al Viro wrote:
On Sun, Apr 03, 2005 at 02:30:11PM +0200, Dag Arne Osvik wrote:
Yes, but wouldn't it be much better to avoid code like the following,
which may also be wrong (in terms of speed)?
#ifdef CONFIG_64BIT // or maybe CONFIG_X86_64?
#define fast_u32 u64
#else
#define fast_u32 u32
Andreas Schwab wrote:
Dag Arne Osvik <[EMAIL PROTECTED]> writes:
Yes, but wouldn't it be much better to avoid code like the following,
which may also be wrong (in terms of speed)?
#ifdef CONFIG_64BIT // or maybe CONFIG_X86_64?
#define fast_u32 u64
#else
#define fast_u32 u32
#endif
How
On Apr 03, 2005, at 16:25, Kenneth Johansson wrote:
But is this not exactly what Dag Arne Osvik was trying to do ??
uint_fast32_t means that we want at least 32 bits but it's OK with
more if that happens to be faster on this particular architecture.
The problem was that the C99 standard types are
On Sun, 2005-04-03 at 21:23 +0200, Renate Meijer wrote:
> On Apr 3, 2005, at 2:30 PM, Dag Arne Osvik wrote:
>
> > Stephen Rothwell wrote:
> >
> >> On Sun, 03 Apr 2005 13:55:39 +0200 Dag Arne Osvik <[EMAIL PROTECTED]>
> >> wrote:
> >>
> >>> I've been working on a new DES implementation for Linux,
On Apr 3, 2005, at 2:30 PM, Dag Arne Osvik wrote:
Stephen Rothwell wrote:
On Sun, 03 Apr 2005 13:55:39 +0200 Dag Arne Osvik <[EMAIL PROTECTED]> wrote:
I've been working on a new DES implementation for Linux, and ran into
the problem of how to get access to C99 types like uint_fast32_t for
internal
On Sun, Apr 03, 2005 at 02:30:11PM +0200, Dag Arne Osvik wrote:
> Yes, but wouldn't it be much better to avoid code like the following,
> which may also be wrong (in terms of speed)?
>
> #ifdef CONFIG_64BIT // or maybe CONFIG_X86_64?
> #define fast_u32 u64
> #else
> #define fast_u32 u32
>
Dag Arne Osvik <[EMAIL PROTECTED]> writes:
> Yes, but wouldn't it be much better to avoid code like the following,
> which may also be wrong (in terms of speed)?
>
> #ifdef CONFIG_64BIT // or maybe CONFIG_X86_64?
> #define fast_u32 u64
> #else
> #define fast_u32 u32
> #endif
How about using
Stephen Rothwell wrote:
On Sun, 03 Apr 2005 13:55:39 +0200 Dag Arne Osvik <[EMAIL PROTECTED]> wrote:
I've been working on a new DES implementation for Linux, and ran into
the problem of how to get access to C99 types like uint_fast32_t for
internal (not interface) use. In my tests, key setup
On Sun, 03 Apr 2005 13:55:39 +0200 Dag Arne Osvik <[EMAIL PROTECTED]> wrote:
>
> I've been working on a new DES implementation for Linux, and ran into
> the problem of how to get access to C99 types like uint_fast32_t for
> internal (not interface) use. In my tests, key setup on Athlon 64 slows
>
Hi,
I've been working on a new DES implementation for Linux, and ran into
the problem of how to get access to C99 types like uint_fast32_t for
internal (not interface) use. In my tests, key setup on Athlon 64 slows
down by 40% when using u32 instead of uint_fast32_t.
So I wonder if there is any
Hi,
I've been working on a new DES implementation for Linux, and ran into
the problem of how to get access to C99 types like uint_fast32_t for
internal (not interface) use. In my tests, key setup on Athlon 64 slows
down by 40% when using u32 instead of uint_fast32_t.
So I wonder if there is any
On Sun, 03 Apr 2005 13:55:39 +0200 Dag Arne Osvik [EMAIL PROTECTED] wrote:
I've been working on a new DES implementation for Linux, and ran into
the problem of how to get access to C99 types like uint_fast32_t for
internal (not interface) use. In my tests, key setup on Athlon 64 slows
down
Dag Arne Osvik [EMAIL PROTECTED] writes:
Yes, but wouldn't it be much better to avoid code like the following,
which may also be wrong (in terms of speed)?
#ifdef CONFIG_64BIT // or maybe CONFIG_X86_64?
#define fast_u32 u64
#else
#define fast_u32 u32
#endif
How about using just
On Sun, Apr 03, 2005 at 02:30:11PM +0200, Dag Arne Osvik wrote:
Yes, but wouldn't it be much better to avoid code like the following,
which may also be wrong (in terms of speed)?
#ifdef CONFIG_64BIT // or maybe CONFIG_X86_64?
#define fast_u32 u64
#else
#define fast_u32 u32
#endif
...
On Apr 3, 2005, at 2:30 PM, Dag Arne Osvik wrote:
Stephen Rothwell wrote:
On Sun, 03 Apr 2005 13:55:39 +0200 Dag Arne Osvik [EMAIL PROTECTED] wrote:
I've been working on a new DES implementation for Linux, and ran into
the problem of how to get access to C99 types like uint_fast32_t for
internal
On Sun, 2005-04-03 at 21:23 +0200, Renate Meijer wrote:
On Apr 3, 2005, at 2:30 PM, Dag Arne Osvik wrote:
Stephen Rothwell wrote:
On Sun, 03 Apr 2005 13:55:39 +0200 Dag Arne Osvik [EMAIL PROTECTED]
wrote:
I've been working on a new DES implementation for Linux, and ran into
the
On Apr 03, 2005, at 16:25, Kenneth Johansson wrote:
But is this not exactly what Dag Arne Osvik was trying to do ??
uint_fast32_t means that we want at least 32 bits but it's OK with
more if that happens to be faster on this particular architecture.
The problem was that the C99 standard types are
Andreas Schwab wrote:
Dag Arne Osvik [EMAIL PROTECTED] writes:
Yes, but wouldn't it be much better to avoid code like the following,
which may also be wrong (in terms of speed)?
#ifdef CONFIG_64BIT // or maybe CONFIG_X86_64?
#define fast_u32 u64
#else
#define fast_u32 u32
#endif
How
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
On Mon, 4 Apr 2005, Dag Arne Osvik wrote:
(...) And, at least in
theory, long may even provide less than 32 bits.
Are you sure?
My copy of famous C book by B. W. Kernighan and D. Ritchie says that
sizeof(short) = sizeof(int) = sizeof(long)
and
sizeof(short) = 16,
sizeof(int) = 16,
sizeof(long) =
Grzegorz Kulewski wrote:
On Mon, 4 Apr 2005, Dag Arne Osvik wrote:
(...) And, at least in theory, long may even provide less than 32 bits.
Are you sure?
My copy of famous C book by B. W. Kernighan and D. Ritchie says that
sizeof(short) = sizeof(int) = sizeof(long)
and
sizeof(short) = 16,
On Mon, Apr 04, 2005 at 12:48:04AM +0200, Dag Arne Osvik wrote:
Andreas Schwab wrote:
Dag Arne Osvik [EMAIL PROTECTED] writes:
Yes, but wouldn't it be much better to avoid code like the following,
which may also be wrong (in terms of speed)?
#ifdef CONFIG_64BIT // or maybe
Dag Arne Osvik [EMAIL PROTECTED] wrote:
... and with such name 99% will assume (at least at the first reading)
that it _is_ 32bits. We have more than enough portability bugs as it
is, no need to invite more by bad names.
Agreed. The way I see it there are two reasonable options. One is to
57 matches
Mail list logo
