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 9:09 PM, Blaisorblade wrote:
For Jörn Engel and the issue he opened: at the end of this mail I
describe
another bug caught by 2.95 and not by 3.x.
On Tuesday 05 April 2005 22:18, Renate Meijer wrote:
On Apr 5, 2005, at 8:53 PM, Blaisorblade wrote:
On Tuesday 05 April 2005 20
On Apr 6, 2005, at 9:09 PM, Blaisorblade wrote:
For Jörn Engel and the issue he opened: at the end of this mail I
describe
another bug caught by 2.95 and not by 3.x.
On Tuesday 05 April 2005 22:18, Renate Meijer wrote:
On Apr 5, 2005, at 8:53 PM, Blaisorblade wrote:
On Tuesday 05 April 2005 20
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 7:33 PM, Jörn Engel wrote:
On Wed, 6 April 2005 19:29:46 +0200, Renate Meijer wrote:
I think its worth the time and trouble to take this up with the gcc
crowd. So if you could provide a list of things 3.3 misses, i'm sure
the gcc-crowd would like it.
If you volunteer to do work
t;it's old,
drop support for it", but rely on the "dont rely on compiler internals
or at least stick them on one place where everyone can find them
easily, instead of peppering the entire codebase with them" argument.
Regards,
Renate Meijer.
-
To unsubscribe from this list:
On Apr 6, 2005, at 1:32 PM, Jörn Engel wrote:
On Tue, 5 April 2005 22:18:26 +0200, Renate Meijer wrote:
If a function is prefixed with a double underscore, this implies the
function is internal to
the compiler, and may change at any time, since it's not governed by
some sort of standard.
Hence
On Apr 6, 2005, at 1:32 PM, Jörn Engel wrote:
On Tue, 5 April 2005 22:18:26 +0200, Renate Meijer wrote:
If a function is prefixed with a double underscore, this implies the
function is internal to
the compiler, and may change at any time, since it's not governed by
some sort of standard.
Hence
for it, but rely on the dont rely on compiler internals
or at least stick them on one place where everyone can find them
easily, instead of peppering the entire codebase with them argument.
Regards,
Renate Meijer.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On Apr 6, 2005, at 7:33 PM, Jörn Engel wrote:
On Wed, 6 April 2005 19:29:46 +0200, Renate Meijer wrote:
I think its worth the time and trouble to take this up with the gcc
crowd. So if you could provide a list of things 3.3 misses, i'm sure
the gcc-crowd would like it.
If you volunteer to do work
On Apr 5, 2005, at 8:53 PM, Blaisorblade wrote:
On Tuesday 05 April 2005 20:47, Renate Meijer wrote:
On Apr 5, 2005, at 6:48 PM, Greg KH wrote:
-stable review patch. If anyone has any objections, please let us
know.
--
Uses __va_copy instead of va_copy since some old versions
are fixing a bug that is better solved
by downloading
a more recent version of gcc.
Regards,
Renate Meijer.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.h
, that cunning plan is undone.
Furthermore, I think it's wise to convince the community that if not
needed, integers should not be specified
by any specific width.
Regards,
Renate Meijer.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
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
are fixing a bug that is better solved
by downloading
a more recent version of gcc.
Regards,
Renate Meijer.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
On Apr 5, 2005, at 8:53 PM, Blaisorblade wrote:
On Tuesday 05 April 2005 20:47, Renate Meijer wrote:
On Apr 5, 2005, at 6:48 PM, Greg KH wrote:
-stable review patch. If anyone has any objections, please let us
know.
--
Uses __va_copy instead of va_copy since some old versions
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
, that cunning plan is undone.
Furthermore, I think it's wise to convince the community that if not
needed, integers should not be specified
by any specific width.
Regards,
Renate Meijer.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED
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 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.
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
s kind of overly
explicit typing. It's much easier to make assumptions about integer
size unwittingly than it is to avoid them. I used to assume (for
instance) that sizeof(int) == sizeof(long) == sizeof(void *) at one
point in my career. Fortunately, reality soon asserted itself again.
Regard
explicit typing. It's much easier to make assumptions about integer
size unwittingly than it is to avoid them. I used to assume (for
instance) that sizeof(int) == sizeof(long) == sizeof(void *) at one
point in my career. Fortunately, reality soon asserted itself again.
Regards,
Renate Meijer
On Apr 1, 2005, at 3:09 PM, linux-os wrote:
[PATCH snipped]
Cruel joke. Now 80 percent of the Intel clones won't boot.
Those are the ones that run industry, you know, the stuff that
is necessary to earn money.
Without i386 support, you don't have any embedded systems. You
need to use the garbage
On Apr 1, 2005, at 3:09 PM, linux-os wrote:
[PATCH snipped]
Cruel joke. Now 80 percent of the Intel clones won't boot.
Those are the ones that run industry, you know, the stuff that
is necessary to earn money.
Without i386 support, you don't have any embedded systems. You
need to use the garbage
On Mar 28, 2005, at 9:39 PM, [EMAIL PROTECTED] wrote:
On Mar 28, 2005, at 9:39 PM, [EMAIL PROTECTED] wrote:
I already posted one, posts ago.
[snip]
Imporved version:
[snip]
char *dummy = (char *)malloc(1);
That cast is not supposed to be there, is it? (To pretake it: it's
bad.)
What is so bad
On Mar 28, 2005, at 9:39 PM, [EMAIL PROTECTED] wrote:
On Mar 28, 2005, at 9:39 PM, [EMAIL PROTECTED] wrote:
I already posted one, posts ago.
[snip]
Imporved version:
[snip]
char *dummy = (char *)malloc(1);
That cast is not supposed to be there, is it? (To pretake it: it's
bad.)
What is so bad
27 matches
Mail list logo