Buggy compilers are indefensible, yes, but why try to apologise for it?
I dont see it as a bug. Without an 'L' the right hand side of that
expression is a 16 bit int. For which 65536 is out of range. If I
wrote 'int y = 65535; long x = y;' then I would get the same result for
the same reason.
On Wed, Dec 22, 2004 at 12:26:03PM +, Pete French wrote:
Buggy compilers are indefensible, yes, but why try to apologise for it?
I dont see it as a bug. Without an 'L' the right hand side of that
expression is a 16 bit int. For which 65536 is out of range. If I
wrote 'int y = 65535;
The type of a decimal integer constant without any suffix is the first
of 'int', 'long', 'long long' in which the constant can be represented.
It is ? Well, you learn something new every day I guess! I stand
corrected in that case. Appologies.
(For C89 it was the first of 'int', 'long',
On Wed, 22 Dec 2004 14:25:14 +
Pete French [EMAIL PROTECTED] wrote:
The type of a decimal integer constant without any suffix is the first
of 'int', 'long', 'long long' in which the constant can be represented.
It is ? Well, you learn something new every day I guess! I stand
corrected
On Wed, Dec 22, 2004 at 02:25:14PM +, Pete French wrote:
The type of a decimal integer constant without any suffix is the first
of 'int', 'long', 'long long' in which the constant can be represented.
It is ? Well, you learn something new every day I guess! I stand
corrected in that
I'd really like to see support for the AMD64 architecture become rock solid,
too, because 64 bit Athlons are starting to sell at great prices.
Sadly I went back to running i386 on my AMD64's - not because of problems
with FreeBSD, but because of problems with ports. It seems that theres a lot
It's the C language. While it's claimed to be portable, it really doesn't
address integer size and endianism well enough.
Oddly enough, even FORTRAN did a better job. You could declare a variable
to be INTEGER*4 and that would be that, regardless of architecture.
Which ports were causing you
On Tue, 2004-Dec-21 11:17:22 +, Pete French wrote:
I'd really like to see support for the AMD64 architecture become rock solid,
too, because 64 bit Athlons are starting to sell at great prices.
Sadly I went back to running i386 on my AMD64's - not because of problems
with FreeBSD, but
It's the C language. While it's claimed to be portable, it really doesn't
address integer size and endianism well enough.
All the more reason to be careful you might have thought :-) Mind you,
trying to explain to students why 'long x = 65535;' set x equal to -1
always made me feel like I was
On Tue, Dec 21, 2004 at 07:08:50PM +, Pete French wrote:
It's the C language. While it's claimed to be portable, it really doesn't
address integer size and endianism well enough.
All the more reason to be careful you might have thought :-) Mind you,
trying to explain to students why
On Wed, Dec 22, 2004 at 05:59:14AM +1100, Peter Jeremy wrote:
One problem is that Unix first became popular (outside academia) with
the advent of the 32-bit workstations and then took off with the rise
of Linux on 32-bit i386. Lots of Unix code has never seen an environment
were sizeof(int)
there will be a 5.3.1-RELEASE.
Would you please explain what are these ``glitches'' and ``performance
issues''? Are they believed to have been fixed in recent -CURRENT?
How about the problems the amd64 platform has with memory configurations
above 4GB? These prevent a successful install
At 10:40 PM 12/18/2004, Xin LI wrote:
Would you please explain what are these ``glitches'' and ``performance
issues''? Are they believed to have been fixed in recent -CURRENT?
5.3 has been reported to be significantly slower on many machines --
something that we've seen in our own tests. Some
Brett Glass wrote:
Would anyone else besides me like to see a 5.3.1 minor release
sometime around, say, February?
No, but quite a few people would like to see a 5.4 minor release
sometime around, say, late February or early March.
Colin Percival
At 06:14 PM 12/19/2004, Colin Percival wrote:
No, but quite a few people would like to see a 5.4 minor release
sometime around, say, late February or early March.
That would work too. It's a slightly shorter than usual time between point
releases, but then, a lot of progress is being made
else besides me like to see a 5.3.1 minor release
sometime around, say, February?
--Brett Glass
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
(rather
than 4.10 or 4.11) for production servers.
Would anyone else besides me like to see a 5.3.1 minor release
sometime around, say, February?
Why not just track RELENG_5? It would give you the same thing.
Andrew
___
[EMAIL PROTECTED
(rather
than 4.10 or 4.11) for production servers.
RELENG_5_3 is considered ``errata branch'' so if there is some
serious issues then some of us may request an errata candidate
to re@ and there may be an ``errata advisory''. Generally
speaking, I don't think there will be a 5.3.1-RELEASE.
Would
18 matches
Mail list logo
