Re: misc/144749: [libstand] [patch] make assert.c use abort(3) instead of exit(3)

2010-03-15 Thread Bruce Evans
On Sun, 14 Mar 2010, Alexander Best wrote: Description: gcc complaints about the use of exit() in assert.c: /usr/src/lib/libstand/assert.c:43: warning: implicit declaration of function 'exit' It's not clear where this should be declared, or even it must exist. exit() might be supplied by

Re: misc/144749: [libstand] [patch] make assert.c use abort(3) instead of exit(3)

2010-03-15 Thread Bruce Evans
The following reply was made to PR kern/144749; it has been noted by GNATS. From: Bruce Evans b...@optusnet.com.au To: Alexander Best alexbes...@wwu.de Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org Subject: Re: misc/144749: [libstand] [patch] make assert.c use abort(3) instead

Re: bin/145230: mtree(8) -P is broken because l* functions aren't being used

2010-04-02 Thread Bruce Evans
On Wed, 31 Mar 2010, Garrett Cooper wrote: Description: As discovered when reviewing mtree(8) as part of bin/144411, there are a number of items with -P that doesn't work... all chown, chmod, and stat calls for instance are the non-l variety, which means that unfortunately the file

Re: bin/145748: hexdump(1) %s format qualifier broken

2010-04-21 Thread Bruce Evans
On Wed, 21 Apr 2010, Garrett Cooper wrote: On Tue, Apr 20, 2010 at 7:33 AM, Wayne Sierke w...@au.dyndns.ws wrote: The fact that %4s fails and isn't noted in the addendum is a failure according to the specifications of hexdump as per the manpage; %.4s passing is a reasonable workaround for

Re: kern/147226: read(fd, buffer, len) returns -1 immediately, if len gt;=2147483648

2010-06-02 Thread Bruce Evans
On Mon, 31 May 2010, Garrett Cooper wrote: The following reply was made to PR kern/147226; it has been noted by GNATS. The following reply is only to to the addresses in the header mangled by GNATS, so it might be lost by GNATS as usual: From: Bruce Cran br...@cran.org.uk To:

Re: kern/144307: ENOENT set unnecessarily under certain circumstances when malloc is called / fails

2010-06-28 Thread Bruce Evans
On Mon, 28 Jun 2010, Jaakko Heinonen wrote: On 2010-06-28, Garrett Cooper wrote: Or the malloc(3) call could be fixed with the couple of lines I noted (well, adlibbed of course... Which I agree with, but shouldn't we fix malloc(3) (and any other function calls that depend on

Re: bin/54784: find(1) -ls wastes space

2010-07-30 Thread Bruce Evans
On Thu, 29 Jul 2010 jil...@freebsd.org wrote: Synopsis: find(1) -ls wastes space State-Changed-From-To: open-closed State-Changed-By: jilles State-Changed-When: Thu Jul 29 23:24:55 UTC 2010 State-Changed-Why: I don't think there is a good way to fix this. Iterating over all users with

Re: bin/150772: csup should include limits.h instead of sys/limits.h

2010-09-21 Thread Bruce Evans
On Tue, 21 Sep 2010, Derrick Brashear wrote: Description: All but one inclusion of limits.h use the portable (/usr/include) header path; One uses sys/limits.h, which is included by limits.h. I wonder if we could properly break unportable includers. In this case, maybe use one of: A. Don't

Re: bin/150772: csup should include limits.h instead of sys/limits.h

2010-09-21 Thread Bruce Evans
The following reply was made to PR bin/150772; it has been noted by GNATS. From: Bruce Evans b...@optusnet.com.au To: Derrick Brashear sha...@gmail.com Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org Subject: Re: bin/150772: csup should include limits.h instead of sys/limits.h Date

Re: bin/27687: fsck(8) wrapper is not properly passing options to fsck_fstype

2010-09-24 Thread Bruce Evans
On Fri, 24 Sep 2010 bru...@freebsd.org wrote: Synopsis: fsck(8) wrapper is not properly passing options to fsck_fstype Responsible-Changed-From-To: freebsd-bugs-freebsd-fs Responsible-Changed-By: brucec Responsible-Changed-When: Fri Sep 24 20:52:17 UTC 2010 Responsible-Changed-Why: Over to

Re: misc/150972: symbolic link bug

2010-09-26 Thread Bruce Evans
On Sun, 26 Sep 2010, Kevin K. Han wrote: Description: Create a directory on the root folder, for example (/whatever). Switch to user's home directory (cd /usr/home/username) ... from now onwards, work in this directory: Create a symbolic link from inside a user's home (ln -s /whatever .)

Re: misc/150972: symbolic link bug

2010-09-26 Thread Bruce Evans
The following reply was made to PR misc/150972; it has been noted by GNATS. From: Bruce Evans b...@optusnet.com.au To: Kevin K. Han ikevin@revvo.org Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org Subject: Re: misc/150972: symbolic link bug Date: Mon, 27 Sep 2010 06:25:42 +1000

Re: kern/151304: patch - definitions of variables tested by ASSERT_ATOMIC_LOAD_PTR

2010-10-08 Thread Bruce Evans
On Fri, 8 Oct 2010, Svatopluk Kraus wrote: Description: A macro ASSERT_ATOMIC_LOAD_PTR() hits in colfire port I work on. It is possibly due to use of GNU GCC (4.5.1) compiler -Os option (size optimalization). The macro is applied on four places: Perhaps gcc-4.5.1 -Os is doing invalid

Re: kern/151304: patch - definitions of variables tested by ASSERT_ATOMIC_LOAD_PTR

2010-10-08 Thread Bruce Evans
The following reply was made to PR kern/151304; it has been noted by GNATS. From: Bruce Evans b...@optusnet.com.au To: Svatopluk Kraus onw...@gmail.com Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: kern/151304: patch - definitions of variables tested

Re: bin/144306: [libm] [patch] Nasty bug in jn(3)

2010-11-10 Thread Bruce Evans
On Tue, 9 Nov 2010, Ulrich [utf-8] Sp??rlein wrote: Hello Steve, I saw your updated patch for jnf(3) on the mailing list and was wondering what the correct values for your test case would look like? I'm asking because on Ubuntu I get slightly different values. Especially disturbing is, that for

Re: bin/144306: [libm] [patch] Nasty bug in jn(3)

2010-11-10 Thread Bruce Evans
On Wed, 10 Nov 2010, Bruce Evans wrote: [...unrelated] Just noticed a minor bug in the float version: from the PR: % diff --git a/lib/msun/src/e_jnf.c b/lib/msun/src/e_jnf.c % index 3bbf7b7..d045bb05 100644 % --- a/lib/msun/src/e_jnf.c % +++ b/lib/msun/src/e_jnf.c % @@ -152,7 +152,12

Re: bin/152154: /bin/csh /bin/tcsh improperly diddle termios flags

2010-11-12 Thread Bruce Evans
On Thu, 11 Nov 2010, Ronald F.Guilmette wrote: Description: Apparently, /bin/csh (aka /bin/tcsh) is diddling termios flags, in particular the ECHO flag, for no apparently good reason and without ever even having been asked to do so. The result is that the /usr/bin/script program, when

Re: bin/152154: /bin/csh /bin/tcsh improperly diddle termios flags

2010-11-12 Thread Bruce Evans
The following reply was made to PR bin/152154; it has been noted by GNATS. From: Bruce Evans b...@optusnet.com.au To: Ronald F.Guilmette r...@tristatelogic.com Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: bin/152154: /bin/csh /bin/tcsh improperly diddle termios

Re: bin/152154: /bin/csh /bin/tcsh improperly diddle termios flags

2010-11-12 Thread Bruce Evans
The following reply was made to PR bin/152154; it has been noted by GNATS. From: Bruce Evans b...@optusnet.com.au To: Bruce Evans b...@optusnet.com.au Cc: Ronald F.Guilmette r...@tristatelogic.com, freebsd-bugs@FreeBSD.org, freebsd-gnats-sub...@freebsd.org Subject: Re: bin/152154: /bin

Re: kern/152162: [syscons] On syscons, pressing delete key results in pressing backspace.

2010-11-28 Thread Bruce Evans
On Sun, 21 Nov 2010, Jilles Tjoelker wrote: With the new libteken terminal emulator code in 9-current, syscons is now much like xterm. It appears that Backspace is still ^H, but Delete is now ^[[3~ instead of ^?. That is a bug, but libteken in syscons mode doesn't have it. Termios only

Re: kern/133583: [libm] fma(3) does not respect rounding mode using extended precision

2010-12-03 Thread Bruce Evans
On Fri, 3 Dec 2010 d...@freebsd.org wrote: Synopsis: [libm] fma(3) does not respect rounding mode using extended precision Thanks for the report! This limitation is described in the source for fma(), and unfortunately, it is unlikely to ever change. There are several reasons: - We are a long

Re: kern/162741: [PATCH] vm_kmem_size miscalculated due to int type overflow sometimes

2011-11-22 Thread Bruce Evans
On Mon, 21 Nov 2011, Adam McDougall wrote: Description: [Misformatted lines deleted] Fix: Patch attached with submission follows: --- sys/kern/kern_malloc.c.orig 2011-11-21 12:19:25.712591472 -0500 +++ sys/kern/kern_malloc.c 2011-11-21 17:25:11.831042640 -0500 @@ -704,10 +704,10

Re: kern/162741: [PATCH] vm_kmem_size miscalculated due to int type overflow sometimes

2011-11-22 Thread Bruce Evans
The following reply was made to PR kern/162741; it has been noted by GNATS. From: Bruce Evans b...@optusnet.com.au To: Adam McDougall mcdou...@egr.msu.edu Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org Subject: Re: kern/162741: [PATCH] vm_kmem_size miscalculated due to int type

Re: misc/162952: Problems including netinet/tcp_var.h

2011-11-29 Thread Bruce Evans
On Tue, 29 Nov 2011, Emil wrote: FreeBSD $HOSTNAME.local 8.2-RELEASE FreeBSD 8.2-RELEASE #3: Sat Apr 16 09:20:53 CEST 2011 emil@$HOSTNAME.local:/usr/obj/usr/src/sys/IPSEC i386 Description: When attempting to include netinet/tcp_var.h in a c++ file, the compiler throws a number of

Re: misc/162952: Problems including netinet/tcp_var.h

2011-11-29 Thread Bruce Evans
The following reply was made to PR misc/162952; it has been noted by GNATS. From: Bruce Evans b...@optusnet.com.au To: Emil the_mix_r...@hotmail.com Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org Subject: Re: misc/162952: Problems including netinet/tcp_var.h Date: Wed, 30 Nov 2011

Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs.

2011-12-05 Thread Bruce Evans
On Mon, 5 Dec 2011, Petr Salinger wrote: Description: It is not possible to read in chunks from linprocfs and procfs. It is a regression against stable-8. I suspect it is due to changes of sbuf implementation between 8 and 9. Some files are rather big (over 4KB) and it is really standard to

Re: kern/163076: It is not possible to read in chunks from linprocfs and procfs.

2011-12-05 Thread Bruce Evans
The following reply was made to PR kern/163076; it has been noted by GNATS. From: Bruce Evans b...@optusnet.com.au To: Petr Salinger petr.salin...@seznam.cz Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org Subject: Re: kern/163076: It is not possible to read in chunks from linprocfs

Re: bin/162659: Can#39; t install FreeBSD-amd64-9.0-RC2 on disk less than 6Go (/mnt: out of inodes)

2011-12-13 Thread Bruce Evans
On Tue, 13 Dec 2011, [ISO-8859-1] Olivier Cochard-Labb? wrote: The following reply was made to PR bin/162659; it has been noted by GNATS. THe following reply probably won't be noted by gnats, since gnats created an incomplete Cc list as usual. I've did some tests: The number of inode after

Re: bin/162659: Can#39; t install FreeBSD-amd64-9.0-RC2 on disk less than 6Go (/mnt: out of inodes)

2011-12-13 Thread Bruce Evans
On Wed, 14 Dec 2011, Bruce Evans wrote: On Tue, 13 Dec 2011, [ISO-8859-1] Olivier Cochard-Labb? wrote: The following reply was made to PR bin/162659; it has been noted by GNATS. THe following reply probably won't be noted by gnats, since gnats created an incomplete Cc list as usual. I've

Re: misc/163871: 'script' save endline as ^M

2012-01-06 Thread Bruce Evans
On Fri, 6 Jan 2012, Eugen Konkov wrote: Description: there must not be ^M endline style How-To-Repeat: #script Script done, output file is typescript when look into 'typesript' file in 'mc' you can see ^M as endline Edit src/sys/dev/et/if_etreg.h^M Add delta 1.4.2.2

Re: misc/163871: 'script' save endline as ^M

2012-01-07 Thread Bruce Evans
The following reply was made to PR bin/163871; it has been noted by GNATS. From: Bruce Evans b...@optusnet.com.au To: Bruce Evans b...@optusnet.com.au Cc: Eugen Konkov kes-...@yandex.ru, freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org Subject: Re: misc/163871: 'script' save

Re: bin/163934: [patch] usbconfig(8) sends help output to stderr instead of stdout

2012-01-09 Thread Bruce Evans
On Sun, 8 Jan 2012, Warren Block wrote: Description: usbconfig(8)'s -h option prints output to stderr. This output is not due to an error, and is already 28 lines line. A typical terminal will not display it all, so the user has to redirect stderr to view it with less or other utilities.

Re: bin/163934: [patch] usbconfig(8) sends help output to stderr instead of stdout

2012-01-10 Thread Bruce Evans
On Mon, 9 Jan 2012, Warren Block wrote: The user can request usage() output with -h or --help or something equivalent, and that output should go to stdout because it's not an error and that data is what was requested. IMO, of course. This should probably be implemented by passing a FILE

Re: bin/164535: ps(1) truncates command to screen size even when stdout is not a tty

2012-01-27 Thread Bruce Evans
On Fri, 27 Jan 2012, Marcus Reid wrote: Description: ps(1) truncates long commands to the size of the screen even when stdout is not a terminal. This is counter-intuitive and differs from another implementation I looked at. Output of ps | grep differs depending on how big your terminal

Re: kern/164656: Add size_t declaration to ucontext.h of 10-CURRENT

2012-01-30 Thread Bruce Evans
On Tue, 31 Jan 2012, Jyun-Yan You wrote: Description: ucontext.h does not include any header file that defines size_t. If we write a program that includes sys/ucontext.h, it may cause compilation errors. ports/164654 is the real case. -current added 2 new prototypes with 5 bugs altogether;

Re: kern/164656: Add size_t declaration to ucontext.h of 10-CURRENT

2012-01-30 Thread Bruce Evans
The following reply was made to PR kern/164656; it has been noted by GNATS. From: Bruce Evans b...@optusnet.com.au To: Jyun-Yan You jy...@cs.nctu.edu.tw Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: kern/164656: Add size_t declaration to ucontext.h of 10-CURRENT Date

Re: kern/164793: 'write' system call violates POSIX standard

2012-02-05 Thread Bruce Evans
The following reply was made to PR standards/164793; it has been noted by GNATS. From: Bruce Evans b...@optusnet.com.au To: Nicolas Bourdaud nicolas.bourd...@gmail.com Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org Subject: Re: kern/164793: 'write' system call violates POSIX

Re: kern/164793: 'write' system call violates POSIX standard

2012-02-15 Thread Bruce Evans
On Wed, 15 Feb 2012, Nicolas Bourdaud wrote: On 05/02/2012 19:54, Bruce Evans wrote: I think this is actually a bug in POSIX (XSI). Most programs aren't prepared to deal with short writes, and returning an error like truncate() is specified to is adequate. I disagree, I think that most

Re: kern/164793: 'write' system call violates POSIX standard

2012-02-15 Thread Bruce Evans
The following reply was made to PR standards/164793; it has been noted by GNATS. From: Bruce Evans b...@optusnet.com.au To: Nicolas Bourdaud nicolas.bourd...@gmail.com Cc: Bruce Evans b...@optusnet.com.au, freebsd-gnats-sub...@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: kern/164793

Re: kern/19402: Signals 127 and 128 cannot be detected in wait4() interface

2012-04-30 Thread Bruce Evans
The following reply was made to PR kern/19402; it has been noted by GNATS. From: Bruce Evans b...@optusnet.com.au To: Jilles Tjoelker jil...@stack.nl Cc: bug-follo...@freebsd.org, ne...@segfault.kiev.ua, b...@freebsd.org Subject: Re: kern/19402: Signals 127 and 128 cannot be detected in wait4

Re: kern/169282: utimes does not update st_mtim.tv_nsec when utimes(file, NULL)

2012-06-21 Thread Bruce Evans
On Thu, 21 Jun 2012, Shinji KOBAYASHI wrote: Description: man utimes 2 shows that utimes(file, NULL) updates file modified time to current time. But the sample code shows tv_mtim.tv_nsec equals 0, after utimes(file, NULL). It sets tv_mtim to the current time in the current timestamp

Re: kern/169282: utimes does not update st_mtim.tv_nsec when utimes(file, NULL)

2012-06-21 Thread Bruce Evans
The following reply was made to PR kern/169282; it has been noted by GNATS. From: Bruce Evans b...@optusnet.com.au To: Shinji KOBAYASHI sk...@moss.gr.jp Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org Subject: Re: kern/169282: utimes does not update st_mtim.tv_nsec when utimes

Re: kern/170203: [kern] piped dd's don't behave sanely when dealing with a fifo

2012-07-26 Thread Bruce Evans
On Thu, 26 Jul 2012, Garrett Cooper wrote: Description: Creating a fifo and then dd'ing across the fifo using /dev/zero doesn't seem to yield the behavior one would expect to have; dd should either exit thanks to SIGPIPE being sent or the count being completed. Furthermore, the count is

Re: kern/170203: [kern] piped dd's don't behave sanely when dealing with a fifo

2012-07-26 Thread Bruce Evans
The following reply was made to PR kern/170203; it has been noted by GNATS. From: Bruce Evans b...@optusnet.com.au To: Garrett Cooper yaneg...@gmail.com Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org Subject: Re: kern/170203: [kern] piped dd's don't behave sanely when dealing

Re: kern/170203: [kern] piped dd's don't behave sanely when dealing with a fifo

2012-07-27 Thread Bruce Evans
On Fri, 27 Jul 2012, David Xu wrote: On 2012/7/27 10:07, Bruce Evans wrote: I think it's working almost as expected. Large blocks give non-atomic I/O, so the reader sees small blocks, then EOF when it gets ahead of the writer. This always happens without SMP. Not is a bug (debugged below

Re: kern/170203: [kern] piped dd's don't behave sanely when dealing with a fifo

2012-07-27 Thread Bruce Evans
The following reply was made to PR kern/170203; it has been noted by GNATS. From: Bruce Evans b...@optusnet.com.au To: davi...@freebsd.org Cc: Bruce Evans b...@optusnet.com.au, Garrett Cooper yaneg...@gmail.com, freebsd-bugs@FreeBSD.org, freebsd-gnats-sub...@freebsd.org Subject: Re: kern

Re: bin/170206: complex arcsinh, log, etc.

2012-07-27 Thread Bruce Evans
On Wed, 25 Jul 2012, Stephen Montgomery-Smith wrote: This function seems to be able to compute clog with a worst case relative error of 4 or 5 ULP. ... I lost your previous reply about this after reading just the first part. Please resend if interested. First part recovered by vidcontrol:

Re: bin/170206: complex arcsinh, log, etc.

2012-07-27 Thread Bruce Evans
The following reply was made to PR bin/170206; it has been noted by GNATS. From: Bruce Evans b...@optusnet.com.au To: Stephen Montgomery-Smith step...@freebsd.org Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: bin/170206: complex arcsinh, log, etc. Date: Sat, 28 Jul

Re: bin/170206: complex arcsinh, log, etc.

2012-07-27 Thread Bruce Evans
On Fri, 27 Jul 2012, Stephen Montgomery-Smith wrote: On 07/27/2012 09:26 AM, Bruce Evans wrote: VC For clog, the worst case that I've found so far has x^2+y^2-1 ~= 1e-47: VC VC x = 0.9995559107901499373838305473327636718750 VC y = VC

Re: bin/170206: complex arcsinh, log, etc.

2012-07-27 Thread Bruce Evans
The following reply was made to PR bin/170206; it has been noted by GNATS. From: Bruce Evans b...@optusnet.com.au To: Stephen Montgomery-Smith step...@missouri.edu Cc: Bruce Evans b...@optusnet.com.au, Stephen Montgomery-Smith step...@freebsd.org, freebsd-gnats-sub...@freebsd.org

Re: bin/170206: complex arcsinh, log, etc.

2012-07-27 Thread Bruce Evans
On Fri, 27 Jul 2012, Stephen Montgomery-Smith wrote: On 07/27/2012 09:26 AM, Bruce Evans wrote: % hm1 = -1; % for (i=0;i12;i++) hm1 += val[i]; % return (cpack(0.5 * log1p(hm1), atan2(y, x))); It is the trailing terms that I think don't work right here. You sort them and add from

Re: bin/170206: complex arcsinh, log, etc.

2012-07-27 Thread Bruce Evans
The following reply was made to PR bin/170206; it has been noted by GNATS. From: Bruce Evans b...@optusnet.com.au To: Stephen Montgomery-Smith step...@missouri.edu Cc: Bruce Evans b...@optusnet.com.au, Stephen Montgomery-Smith step...@freebsd.org, freebsd-gnats-sub...@freebsd.org

Re: bin/170206: complex arcsinh, log, etc.

2012-07-28 Thread Bruce Evans
On Sat, 28 Jul 2012, Stephen Montgomery-Smith wrote: On 07/28/2012 12:25 AM, Bruce Evans wrote: #defineDEDBL_EPSILON// for clarity (1) 1 + DE/2= 1 (half way case rounded down to even) (2) 1 + DE/2 + DE/2 = 1 (double rounding) (3) DE/2 + DE/2 + 1

Re: bin/170206: complex arcsinh, log, etc.

2012-07-28 Thread Bruce Evans
The following reply was made to PR bin/170206; it has been noted by GNATS. From: Bruce Evans b...@optusnet.com.au To: Stephen Montgomery-Smith step...@missouri.edu Cc: Bruce Evans b...@optusnet.com.au, freebsd-bugs@freebsd.org, freebsd-gnats-sub...@freebsd.org, Stephen Montgomery

Re: bin/170206: complex arcsinh, log, etc.

2012-07-28 Thread Bruce Evans
On Sat, 28 Jul 2012, Stephen Montgomery-Smith wrote: Yes, everywhere I said double precision I meant doubled precision. I think the papers by Hull et al were perfectly happy with a ULP of around 4. I have been trying to do a little better, but like you I am noticing that log1p isn't that good

Re: bin/170206: complex arcsinh, log, etc.

2012-07-28 Thread Bruce Evans
On Sat, 28 Jul 2012, Stephen Montgomery-Smith wrote: On 07/28/2012 10:46 AM, Stephen Montgomery-Smith wrote: OK. This clog really seems to work. x*x + y*y - 1 is computed with a ULP less than 0.8. The rest of the errors seem to be due to the implementation of log1p. The ULP of the final

Re: bin/170206: complex arcsinh, log, etc.

2012-07-28 Thread Bruce Evans
The following reply was made to PR bin/170206; it has been noted by GNATS. From: Bruce Evans b...@optusnet.com.au To: Stephen Montgomery-Smith step...@missouri.edu Cc: Bruce Evans b...@optusnet.com.au, freebsd-bugs@FreeBSD.org, freebsd-gnats-sub...@freebsd.org, Stephen Montgomery

Re: bin/170206: complex arcsinh, log, etc.

2012-07-28 Thread Bruce Evans
On Sat, 28 Jul 2012, Stephen Montgomery-Smith wrote: OK. This clog really seems to work. x*x + y*y - 1 is computed with a ULP less than 0.8. The rest of the errors seem to be due to the implementation of log1p. The ULP of the final answer seems to be never bigger than a little over 2. I

Re: bin/170206: complex arcsinh, log, etc.

2012-07-29 Thread Bruce Evans
On Sat, 28 Jul 2012, Stephen Montgomery-Smith wrote: On 07/28/2012 11:15 AM, Stephen Montgomery-Smith wrote: On 07/28/2012 10:46 AM, Stephen Montgomery-Smith wrote: OK. This clog really seems to work. x*x + y*y - 1 is computed with a ULP less than 0.8. The rest of the errors seem to be due

Re: bin/170206: complex arcsinh, log, etc.

2012-07-29 Thread Bruce Evans
The following reply was made to PR bin/170206; it has been noted by GNATS. From: Bruce Evans b...@optusnet.com.au To: Stephen Montgomery-Smith step...@missouri.edu Cc: Bruce Evans b...@optusnet.com.au, freebsd-bugs@FreeBSD.org, freebsd-gnats-sub...@freebsd.org, Stephen Montgomery

Re: kern/170203: [kern] piped dd#39; s don#39; t behave sanely when dealing with a fifo

2012-07-29 Thread Bruce Evans
On Sun, 29 Jul 2012, David Xu wrote: FIFO pipe is quite broken! Beside the bug you have reported, there is another bug, when a writer closed the pipe, select() on reader side will never return ! I am curious that so long time, nobody found the bugs, does it because FIFO is seldom used by

Re: kern/170203: [kern] piped dd#39; s don#39; t behave sanely when dealing with a fifo

2012-07-29 Thread Bruce Evans
On Sun, 29 Jul 2012, David Xu wrote: I have just written two quick-and-dirty test cases: http://people.freebsd.org/~davidxu/patch/fifopipe/fifo_selectread.c http://people.freebsd.org/~davidxu/patch/fifopipe/fifo_selectwrite.c without patch for kernel code, a child process will print out

Re: bin/170206: complex arcsinh, log, etc.

2012-07-29 Thread Bruce Evans
On Sat, 28 Jul 2012, Stephen Montgomery-Smith wrote: On 07/28/2012 09:31 PM, Bruce Evans wrote: On Sat, 28 Jul 2012, Stephen Montgomery-Smith wrote: OK. This clog really seems to work. x*x + y*y - 1 is computed with a ULP less than 0.8. The rest of the errors seem to be due

Re: kern/181127: [PATCH] set{domain, host}name doesn't permit NUL terminated strings that are MAXHOSTNAMELEN long

2013-08-08 Thread Bruce Evans
On Thu, 8 Aug 2013, Garrett Cooper wrote: Synopsis: [PATCH] set{domain,host}name doesn't permit NUL terminated strings that are MAXHOSTNAMELEN long ... Description: The noted link/patch fixes POSIX and generic requirement compliance for set{domain,host}name per the manpages by

Re: kern/181127: [PATCH] set{domain, host}name doesn't permit NUL terminated strings that are MAXHOSTNAMELEN long

2013-08-08 Thread Bruce Evans
The following reply was made to PR kern/181127; it has been noted by GNATS. From: Bruce Evans b...@optusnet.com.au To: Garrett Cooper yaneurab...@gmail.com Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: kern/181127: [PATCH] set{domain, host}name doesn't permit NUL

Re: kern/181127: [PATCH] set{domain, host}name doesn't permit NUL terminated strings that are MAXHOSTNAMELEN long

2013-08-08 Thread Bruce Evans
On Thu, 8 Aug 2013, Garrett Cooper wrote: On Aug 8, 2013, at 4:35 AM, Bruce Evans wrote: On Thu, 8 Aug 2013, Garrett Cooper wrote: Synopsis: [PATCH] set{domain,host}name doesn't permit NUL terminated strings that are MAXHOSTNAMELEN long ... Description: The noted link/patch fixes

Re: kern/181127: [PATCH] set{domain, host}name doesn't permit NUL terminated strings that are MAXHOSTNAMELEN long

2013-08-08 Thread Bruce Evans
The following reply was made to PR kern/181127; it has been noted by GNATS. From: Bruce Evans b...@optusnet.com.au To: Garrett Cooper yaneurab...@gmail.com Cc: Bruce Evans b...@optusnet.com.au, freebsd-gnats-sub...@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: kern/181127: [PATCH] set

Re: kern/181416: socket timeout rounding issue

2013-08-20 Thread Bruce Evans
On Tue, 20 Aug 2013, Vitja Makarov wrote: Description: Recently I was playing with small socket timeouts. setsockopt(2) SO_RCVTIMEO and found a problem with it: if timeout is small enough read(2) may return before timeout is actually expired. I was unable to reproduce this on linux box. I

Re: kern/181416: socket timeout rounding issue

2013-08-20 Thread Bruce Evans
The following reply was made to PR kern/181416; it has been noted by GNATS. From: Bruce Evans b...@optusnet.com.au To: Vitja Makarov vitja.maka...@gmail.com Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org Subject: Re: kern/181416: socket timeout rounding issue Date: Tue, 20 Aug

Re: kern/181439: [headers] sys/wait.h is not enough to use waitid(), but kind of should be.

2013-08-22 Thread Bruce Evans
On Wed, 21 Aug 2013, Jilles Tjoelker wrote: In PR kern/181439, you wrote: [sys/wait.h does not define siginfo_t] POSIX says that sys/wait.h shall define siginfo_t and may make visible all symbols from signal.h. This was even in the 2001 version (under an XSI extension) (waitid was there

Re: misc/184340: PATH_MAX not interoperable with Linux

2013-11-27 Thread Bruce Evans
On Wed, 27 Nov 2013, Brooks Davis wrote: On Wed, Nov 27, 2013 at 11:03:31PM +, David Cundiff wrote: Change PATH_MAX in kernel to 4096 from 1024. Should be harmless and will fix the issue in any program that uses PATH_MAX from the kernel headers. Also would allow longer 32-bit unicode

Re: misc/186699: ddb on i386 and amd64 should be enhanced to show MSR values (enhancement)

2014-02-12 Thread Bruce Evans
On Wed, 12 Feb 2014, Justin Hibbits wrote: Description: On x86 it would be very useful to be able to show MSR values using rdmsr in the debugger. All inline functions in machine/cpufunc.h should be backed by extern functions, as for machine/atomic.h on x86 (this too is broken on other

Re: misc/186699: ddb on i386 and amd64 should be enhanced to show MSR values (enhancement)

2014-02-12 Thread Bruce Evans
The following reply was made to PR misc/186699; it has been noted by GNATS. From: Bruce Evans b...@optusnet.com.au To: Justin Hibbits jhibb...@freebsd.org Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: misc/186699: ddb on i386 and amd64 should be enhanced to show MSR

Re: kern/188247: [PATCH] include/rpcsvc/yp_prot.h: remove typedef of bool.

2014-04-04 Thread Bruce Evans
On Fri, 4 Apr 2014, Yasuhiro KIMURA wrote: Description: There have been typedef of bool in rpcsvc/yp_prot.h since it is added to source tree in August 1994. But there is also definition of bool in stdbool.h, and they conflict when both headers are used. An

Re: kern/188247: [PATCH] include/rpcsvc/yp_prot.h: remove typedef of bool.

2014-04-04 Thread Bruce Evans
The following reply was made to PR kern/188247; it has been noted by GNATS. From: Bruce Evans b...@optusnet.com.au To: Yasuhiro KIMURA y...@utahime.org Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: kern/188247: [PATCH] include/rpcsvc/yp_prot.h: remove typedef

Re: bin/188715: int64 not handled right as arg on badsect(8), possible other issues lurking

2014-04-17 Thread Bruce Evans
On Thu, 17 Apr 2014, Dirk-Willem van Gulik wrote: Description: Was trying to map out some bad blocks prior to temporarily read/empty 4 Tbyte volume using ?badsect(8)? - and returing it. Was expecting to be able to put the sector # into badsect (e.g. 3432631424 from below FSCK output). This

Re: bin/188715: int64 not handled right as arg on badsect(8), possible other issues lurking

2014-04-17 Thread Bruce Evans
The following reply was made to PR bin/188715; it has been noted by GNATS. From: Bruce Evans b...@optusnet.com.au To: Dirk-Willem van Gulik di...@webweaving.org Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: bin/188715: int64 not handled right as arg on badsect(8

Re: kern/181155: [libc] [patch] *access*(2) does not handle invalid amodes properly

2014-04-18 Thread Bruce Evans
On Fri, 18 Apr 2014, Garrett Cooper wrote: And one more thing: fixing this will make FreeBSD more POSIX compliant with this system call ( http://pubs.opengroup.org/onlinepubs/009695299/functions/access.html ), will match the behavior on Linux and NetBSD at least: The access() function may

Re: kern/188952: read after revoke giving error not eof

2014-04-24 Thread Bruce Evans
On Thu, 24 Apr 2014, Justin Cormack wrote: Description: I have this ktrace of revoking a pty device: ... 43214 luajit-2.0.2 CALL revoke(0xfebc8) 43214 luajit-2.0.2 NAMI /dev/pts/1 43214 luajit-2.0.2 RET revoke 0 43214 luajit-2.0.2 CALL read(0x4,0xa4170,0x1000) 43214 luajit-2.0.2 RET

Re: kern/188952: read after revoke giving error not eof

2014-04-24 Thread Bruce Evans
The following reply was made to PR kern/188952; it has been noted by GNATS. From: Bruce Evans b...@optusnet.com.au To: Justin Cormack jus...@specialbusservice.com Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: kern/188952: read after revoke giving error not eof Date

Re: kern/189941: getgroups(2) implements first argument as unsigned int

2014-05-20 Thread Bruce Evans
On Mon, 19 May 2014, Peter Holm wrote: Description: Passing -1 as gidsetlen is not detected. Discovered by ATF. Caught on Ubuntu and OS/X. A typical error from abusing an unsigned variable as a counter. This doesn't even match the API. This bug was in 4.4BSD. The fix seems to be almost

Re: [Bug 191674] New: [tests] printf(%tu, (intmax_t)-1) returns UINT64_MAX on i386, not UINT32_MAX

2014-07-12 Thread Bruce Evans
On Sun, 6 Jul 2014 bugzilla-nore...@freebsd.org wrote: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191674 ... One of the testcases in tools/regression/lib/libc/stdio/test-printbasic.t tests out %tu with -1 and it fails because the testcase is correctly expecting UINT32_MAX, not

Re: bin/153012: iostat(8) requires an argument to -c option

2010-12-11 Thread Bruce Evans
On Fri, 10 Dec 2010, Warren Block wrote: Description: iostat(8) says: -cRepeat the display count times. If no repeat count is specified, the default is infinity. This used to be correct. It said if no wait interval is specified, then the default [for the wait interval] is 1

Re: bin/153012: iostat(8) requires an argument to -c option

2010-12-11 Thread Bruce Evans
The following reply was made to PR bin/153012; it has been noted by GNATS. From: Bruce Evans b...@optusnet.com.au To: Warren Block wbl...@wonkity.com Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org Subject: Re: bin/153012: iostat(8) requires an argument to -c option Date: Sat, 11

Re: Re: bin/153012: iostat(8) requires an argument to -c option

2010-12-15 Thread Bruce Evans
On Tue, 14 Dec 2010, Alexander Best wrote: how do you feel about the wording of the vmstat(8) manual? it would be possible to re-use it for the iostat(8) manual. of course just the -c and -w part. It's even worse than in iostat(8), mainly due to it being more verbose and having a similar

Re: bin/153426: [patch] fsck_msdosfs only works with sector size 512

2010-12-24 Thread Bruce Evans
On Fri, 24 Dec 2010, Keith White wrote: Description: It is possible to create and use an msdos filesystem with 2048-byte sectors; but it is not possible to fsck it. fsck_msdosfs on such a fileystem returns: could not read boot block (Invalid argument) Fix: The following POC

Re: bin/153426: [patch] fsck_msdosfs only works with sector size 512

2010-12-24 Thread Bruce Evans
The following reply was made to PR bin/153426; it has been noted by GNATS. From: Bruce Evans b...@optusnet.com.au To: Keith White kwh...@uottawa.ca Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org Subject: Re: bin/153426: [patch] fsck_msdosfs only works with sector size 512 Date

Re: bin/153600: Path length restrictions in mount/umount tools prevent filesystem mount/unmount

2011-01-01 Thread Bruce Evans
On Sat, 1 Jan 2011, Roger Leigh wrote: t...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 Description: When mount is asked to mount a filesystem on a node whose absolute path is longer than 85 characters in length, the mount fails. Umount also fails under some circumstances,

Re: bin/153600: Path length restrictions in mount/umount tools prevent filesystem mount/unmount

2011-01-01 Thread Bruce Evans
The following reply was made to PR bin/153600; it has been noted by GNATS. From: Bruce Evans b...@optusnet.com.au To: Roger Leigh rle...@debian.org Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: bin/153600: Path length restrictions in mount/umount tools prevent

Re: kern/154006: tcp window probe bug on 64bit

2011-01-14 Thread Bruce Evans
On Sat, 15 Jan 2011, Stefan `Sec` Zehl wrote: Description: On amd64 the PERSIST timer does not get started (and consecquently executed) for tcp connections stalled on a 0-size receive window. This means that no single-byte probe packet is sent, so connections might hang indefinitely. This is

Re: kern/154006: tcp window probe bug on 64bit

2011-01-14 Thread Bruce Evans
The following reply was made to PR kern/154006; it has been noted by GNATS. From: Bruce Evans b...@optusnet.com.au To: Stefan `Sec` Zehl s...@42.org Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org Subject: Re: kern/154006: tcp window probe bug on 64bit Date: Sat, 15 Jan 2011 16:31

Re: kern/154006: tcp window probe bug on 64bit

2011-01-14 Thread Bruce Evans
On Sat, 15 Jan 2011, Bruce Evans wrote: ... Later code in tcp_output uses bogus casts to long and larger code instead: % if (recwin (long)(tp-rcv_adv - tp-rcv_nxt)) % recwin = (long)(tp-rcv_adv - tp-rcv_nxt); % if (recwin (long)TCP_MAXWIN tp-rcv_scale

Re: kern/154006: tcp window probe bug on 64bit

2011-01-14 Thread Bruce Evans
The following reply was made to PR kern/154006; it has been noted by GNATS. From: Bruce Evans b...@optusnet.com.au To: Bruce Evans b...@optusnet.com.au Cc: Stefan `Sec` Zehl s...@42.org, freebsd-bugs@freebsd.org, freebsd-gnats-sub...@freebsd.org Subject: Re: kern/154006: tcp window probe

Re: bin/155000: make(1) doesn't handle .POSIX: correctly

2011-02-24 Thread Bruce Evans
On Thu, 24 Feb 2011, Colin Percival wrote: Description: make(1) doesn't handle .POSIX: correctly. It sucks in sys.mk before it reads the Makefile, and sys.mk has several instances of .if defined(%POSIX) to switch between POSIX and non-POSIX mode; because sys.mk is processed first, there is

Re: bin/155000: make(1) doesn't handle .POSIX: correctly

2011-02-24 Thread Bruce Evans
The following reply was made to PR bin/155000; it has been noted by GNATS. From: Bruce Evans b...@optusnet.com.au To: Colin Percival cperc...@freebsd.org Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org Subject: Re: bin/155000: make(1) doesn't handle .POSIX: correctly Date: Fri, 25

Re: bin/155000: make(1) doesn't handle .POSIX: correctly

2011-02-24 Thread Bruce Evans
On Thu, 24 Feb 2011, Colin Percival wrote: On 02/24/11 14:35, Bruce Evans wrote: Except that there is the opportunity to set %POSIX using make -D. This might be enough in practice. The namespace pollution avoidance is too perfect -- there seems to be no way to set %POSIX or .POSIX

Re: gnu/155309: [PATCH] gcc: backport bswap32() and bswap64()

2011-03-06 Thread Bruce Evans
On Sun, 6 Mar 2011, Martin Matuska wrote: Description: In many ports, we have to deal with patching the missing bswap32() and bswap64() functions. Er, we have these in endian.h. The gcc-4.3 branch SVN revision is 118361, is GPLv2-licensed, applies cleanly and is fully compatible with our

Re: gnu/155309: [PATCH] gcc: backport bswap32() and bswap64()

2011-03-06 Thread Bruce Evans
The following reply was made to PR gnu/155309; it has been noted by GNATS. From: Bruce Evans b...@optusnet.com.au To: Martin Matuska m...@freebsd.org Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org Subject: Re: gnu/155309: [PATCH] gcc: backport bswap32() and bswap64() Date: Sun, 6

Re: misc/156637: sys/types.h can't be included when _XOPEN_SOURCE is defined

2011-04-25 Thread Bruce Evans
The following reply was made to PR misc/156637; it has been noted by GNATS. From: Bruce Evans b...@optusnet.com.au To: Robert Andersson stream...@streambag.se Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: misc/156637: sys/types.h can't be included when _XOPEN_SOURCE

Re: misc/156637: sys/types.h can't be included when _XOPEN_SOURCE is defined

2011-04-25 Thread Bruce Evans
On Mon, 25 Apr 2011, Robert Andersson wrote: Description: When including sys/file.h with _XOPEN_SOURCE defined to 500 or higher, compila tion will fail with a message similar to this one (using clang, gcc fails with a similar message): In file included from main.c:3:

  1   2   >