Re: Will there be a 5.3.1?
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 case. Appologies. > > > (For C89 it was the first of 'int', 'long', 'unsigned long') > > ...and before that ? Did this behaviour change at the end of the 80's - I > don't actually recall seeing it on any compilers after 88 or so I have > to admit. Before that it was just the first of 'int' and 'long'. (According to Harbison/Steele: C:A Reference Manual) > > > No doubt, but if it does the compilers are buggy. > > Apparently so. It seems I've spent the last 18 years or so believing an > untyped integer constant was always of type 'int' when it wasn't true. Well, > maybe I will be less anal about adding 'L' to the ends of my constants from > now on. > > -pcf. -- Erik Trulsson [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Will there be a 5.3.1?
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 in that case. Appologies. > > > (For C89 it was the first of 'int', 'long', 'unsigned long') > > ...and before that ? Did this behaviour change at the end of the 80's - I > don't actually recall seeing it on any compilers after 88 or so I have > to admit. Getting -1 is a bug even in K&R C, unless long is 16 bits :) -- C:>WIN | Directable Mirror Arrays The computer obeys and wins.| A better way to focus the sun You lose and Bill collects. |licences available see |http://www.sohara.org/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Will there be a 5.3.1?
> 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', 'unsigned long') ...and before that ? Did this behaviour change at the end of the 80's - I don't actually recall seeing it on any compilers after 88 or so I have to admit. > No doubt, but if it does the compilers are buggy. Apparently so. It seems I've spent the last 18 years or so believing an untyped integer constant was always of type 'int' when it wasn't true. Well, maybe I will be less anal about adding 'L' to the ends of my constants from now on. -pcf. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Will there be a 5.3.1?
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; long x = y;' then I would get the same result for > the same reason. Wrong. With 16-bit int the constant 65536 has type long. 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. (For C89 it was the first of 'int', 'long', 'unsigned long') (See 6.4.4.1 in the C99 standard.) Your example of 'int y = 65535; long x = y;' on the other hand causes implementation-defined behaviour for 16-bit ints. (As do all other instances of overflow for signed integer types.) > > The correct line is 'long x = 65535L;' which specifies that the constant > is a long. In fact aren't situations like this the precise reason for > having the 'L' as part of the language ? > > > 'long x = 65535;' will not set x to -1, even with 16-bit ints. > > It will and does on certain compilers unfortunately. No doubt, but if it does the compilers are buggy. -- Erik Trulsson [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Will there be a 5.3.1?
> 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. The correct line is 'long x = 65535L;' which specifies that the constant is a long. In fact aren't situations like this the precise reason for having the 'L' as part of the language ? > 'long x = 65535;' will not set x to -1, even with 16-bit ints. It will and does on certain compilers unfortunately. -pcf. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Will there be a 5.3.1?
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) == sizeof(long) == sizeof(void *) isn't true. It's not just int, long, and pointers that cause problems. There is a lot of code out there that tends to play fast and loose with the other types (POSIX?) that IIRC are supposed to be "atomic" -- size_t, time_t, off_t, etc. A while back for kicks I tried to build a 32-bit ILP system that used 64-bit time_t values, just in case it managed to make it to 2038 ;) The base system was actually in really good shape to deal with it, no doubt due to the efforts on alpha and sparc64, and ISTR an effort to use 64-bit longs on i386. Ports on the other hand were a different matter entirely... time_t was bad enough. I suspect size_t and ssize_t are in even worse shape among third-party software. Though if you just change the size of "long" you probably won't run into all that. Craig ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Will there be a 5.3.1?
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 'long x = 65535;' set x equal to -1 > always made me feel like I was trying to appologise for the indefensible! Buggy compilers are indefensible, yes, but why try to apologise for it? 'long x = 65535;' will not set x to -1, even with 16-bit ints. -- Erik Trulsson [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Will there be a 5.3.1?
> 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 trying to appologise for the indefensible! > Which ports were causing you headaches? Unfortunately I really can't remember off the top of my head. I didn't spend too long on it - it was probably amongst some of the stuff GNUstep needs to work with, as the aim of setting the box up was to try and clean up any 32/64 issues there. I intended to go back to it properly and work out exactly what was going wrong at some point, but have not yet had the time. Sorry, not very helpful I know :-( -pcf. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Will there be a 5.3.1?
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 because of problems with ports. It seems that theres a lot >of code out there assuming sizeof(int) = sizeof(long). Which is a shame (and >also depresses me after living through identical problems with the 16->32 >switch. You might have thought people would heave learnt) One of the benefits of the AMD64 is supposed to the its ability to run a mix of 32-bit and 64-bit applications. I recall this being a major problem when I first started working on DEC Alpha's about 6 years ago but haven't noticed it as much recently. (Though one project I'm working on started life on PDP-11's and whilst it's been ported to ILP32, does not like I32LP64). 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) == sizeof(long) == sizeof(void *) isn't true. Hopefully things will improve in the future. -- Peter Jeremy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Will there be a 5.3.1?
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 headaches? --Brett At 04:17 AM 12/21/2004, 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 because of problems with ports. It seems that theres a lot >of code out there assuming sizeof(int) = sizeof(long). Which is a shame (and >also depresses me after living through identical problems with the 16->32 >switch. You might have thought people would heave learnt) > >-pcf. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Will there be a 5.3.1?
> 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 of code out there assuming sizeof(int) = sizeof(long). Which is a shame (and also depresses me after living through identical problems with the 16->32 switch. You might have thought people would heave learnt) -pcf. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Will there be a 5.3.1?
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 because so many people are trying out 5.3. I do have it running on some non-production hardware, and other than a bit of slowness in disk operations and some port problems, it is working pretty well. 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. --Brett ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Will there be a 5.3.1?
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 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Will there be a 5.3.1?
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 of these may have been fixed in -CURRENT, but this would not do us any good. We only run release versions of FreeBSD on our production servers, and then only update them with security fixes. We abolutely WON'T track -CURRENT on a production machine, or take a random sample of it on a random day, due to the many difficulties that this can cause. --Brett Glass ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Will there be a 5.3.1?
Xin LI said: > On Sat, Dec 18, 2004 at 10:00:57PM -0700, Brett Glass wrote: >> I see that there is no scheduled release date for FreeBSD 5.4 >> (which is not a surprise; 5.3 was finalized so recently). >> However, there seem to be glitches and performance issues >> which I need to see resolved before I can move to 5.3.x (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 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. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Will there be a 5.3.1?
On Sat, Dec 18, 2004 at 10:00:57PM -0700, Brett Glass wrote: > I see that there is no scheduled release date for FreeBSD 5.4 > (which is not a surprise; 5.3 was finalized so recently). > However, there seem to be glitches and performance issues > which I need to see resolved before I can move to 5.3.x (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 you please explain what are these ``glitches'' and ``performance issues''? Are they believed to have been fixed in recent -CURRENT? > Would anyone else besides me like to see a 5.3.1 minor release > sometime around, say, February? Maybe 5.4? =-) The 5-STABLE ABI has been frozen so you would not have to fear of a new 5-STABLE release :-) Cheers, -- Xin LI http://www.delphij.net/ See complete headers for GPG key and other information. pgpP2XnrjFZ1R.pgp Description: PGP signature
Re: Will there be a 5.3.1?
On Sat, Dec 18, 2004 at 10:00:57PM -0700, Brett Glass wrote: > I see that there is no scheduled release date for FreeBSD 5.4 > (which is not a surprise; 5.3 was finalized so recently). > However, there seem to be glitches and performance issues > which I need to see resolved before I can move to 5.3.x (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] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
