Re: CVS commit: src/lib/libc/locale
Hi Nozaki-san, On Wed, Jun 02, 2010 at 04:04:52PM +, Takehiko NOZAKI wrote: Module Name: src Committed By: tnozaki Date: Wed Jun 2 16:04:52 UTC 2010 Modified Files: src/lib/libc/locale: bsdctype.c Log Message: uint8_t - unsigned char, int16_t - short. As ever, thank you for looking after our locale code. I was just wondering why this change was made? It seems to be a backwards step to me? Thanks, Alistair
Re: CVS commit: src/usr.bin/sort
On Sun, Jun 06, 2010 at 12:00:33AM +, Thomas Klausner wrote: Modified Files: src/usr.bin/sort: init.c Log Message: Fix typo in comment. Woops! -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/lib/libc/locale
On Sat, Jun 05, 2010 at 11:53:32PM +0200, Alistair Crooks wrote: Module Name: src Committed By: tnozaki Date: Wed Jun 2 16:04:52 UTC 2010 Modified Files: src/lib/libc/locale: bsdctype.c Log Message: uint8_t - unsigned char, int16_t - short. As ever, thank you for looking after our locale code. I was just wondering why this change was made? It seems to be a backwards step to me? I looked at it and it appears to me that it's a change to use non-sized types (that are guaranteed to be large enough) in the in-memory structures. If we ever do a port to a 36-bit machine or whatever it's probably desirable. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/etc
On Fri, Jun 04, 2010 at 02:42:55PM -0400, Christos Zoulas wrote: Modified Files: src/etc: rc rc.subr Log Message: print human readable exit code. + elif [ $1 -eq 127 ] + then + echo stopped with signal $(expr $1 / 256) that can't be right... -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/tests/util/sh
On Thu, Jun 03, 2010 at 06:53:36PM +, Christos Zoulas wrote: # according to the standard, only failing *simple* commands # cause an exit under -e. () is not a simple command. - dcheck '(set -e; (set +e; false; echo OK; false); echo OK)' 'OK OK' - echeck '(set -e; (set +e; false; echo OK; false); echo OK)' 'OK OK' + dcheck '(set -e; (set +e; false; echo OK; false); echo OK)' 'OK' + echeck '(set -e; (set +e; false; echo OK; false); echo OK)' 'OK' The comment explains that failure of the inner subshell should not cause the outer subshell to exit. This means that both the inner and outer echo OK should be performed; but the test expects only the inner echo OK to be performed. Similarly for the other changed tests. Well, I was not sure what to do there [fix the comments, or remove the tests]. Bash and ksh behave the same way as ours does, so I am inclined to believe that the standard is mis-worded or mis-interpreted. There have been at least two different lengthy arguments about this recently. Checking the comment logs for the PRs referenced in the test script will find at least one of those; there was another on tech-userlevel about two years ago. There have been only two undisputed conclusions from those arguments, namely: (1) the standard is vague and in some cases definitely wrong; (2) the issue is so finicky/nitpicky that it's nearly impossible to write mailing-list posts about it that do not contain errors, including posts that attempt to correct errors in prior posts. I have been contemplating trying to work up a formal semantics for this because I don't see any other hope of ever getting it to behave sanely or consistently. However, whitewashing the tests in the meantime isn't particularly helpful. The tests are failing because there are open PRs and sh is broken. If it's more important that the nightly test runs come up clean than that it actually check for correct behavior so sh gets fixed, the test script should at least document what the correct behavior is. I have done this much, although I'm inclined to think the changes should be reverted entirely. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/lib/libc/locale
In message: 20100606041254.gb19...@netbsd.org David Holland dholland-sourcechan...@netbsd.org writes: : On Sat, Jun 05, 2010 at 11:53:32PM +0200, Alistair Crooks wrote: :Module Name: src :Committed By:tnozaki :Date:Wed Jun 2 16:04:52 UTC 2010 : :Modified Files: : src/lib/libc/locale: bsdctype.c : :Log Message: :uint8_t - unsigned char, int16_t - short. : : As ever, thank you for looking after our locale code. : : I was just wondering why this change was made? It seems to be a backwards : step to me? : : I looked at it and it appears to me that it's a change to use : non-sized types (that are guaranteed to be large enough) in the : in-memory structures. If we ever do a port to a 36-bit machine or : whatever it's probably desirable. If you ever port to a 36-bit machine, you are going to have to lie and define int32_t as 'int' anyway Warner
Re: CVS commit: src/lib/libc/locale
On Sat, Jun 05, 2010 at 11:28:31PM -0600, M. Warner Losh wrote: : I looked at it and it appears to me that it's a change to use : non-sized types (that are guaranteed to be large enough) in the : in-memory structures. If we ever do a port to a 36-bit machine or : whatever it's probably desirable. If you ever port to a 36-bit machine, you are going to have to lie and define int32_t as 'int' anyway Well, maybe... it would be sort of interesting to try, actually. -- David A. Holland dholl...@netbsd.org
