Re: svn commit: r322315 - stable/10/sys/netinet

On 09.08.2017 16:26, Michael Tuexen wrote: > Author: tuexen > Date: Wed Aug 9 13:26:12 2017 > New Revision: 322315 > URL: https://svnweb.freebsd.org/changeset/base/322315 > > Log: > MFC r317208: > > Syncoockies can be used in combination with the syncache. If the cache > overflows,

Re: svn commit: r316642 - head/sys/dev/syscons

On 09.04.2017 13:32, Bruce Evans wrote: > How do you initialize actual use of sc->cursor_char? It is only used > when SC_NO_FONT_LOADING is not defined. Configuring SC_PIXEL_MODE > forces SC_NO_FONT_LOADING to be undefined. Except to test sc->cursor_char, I use text console mode with loading

Re: svn commit: r316642 - head/sys/dev/syscons

On 09.04.2017 10:33, Bruce Evans wrote: > On Sun, 9 Apr 2017, Andrey Chernov wrote: > >> On 09.04.2017 7:54, Andrey Chernov wrote: >>> On 08.04.2017 13:00, Bruce Evans wrote: >>>> Log: >>>> Quick fix for removal of the mouse cursor in vga direct grap

Re: svn commit: r316642 - head/sys/dev/syscons

On 09.04.2017 9:46, Bruce Evans wrote: >> Please don't forget that this 5 cells range (0xd0-0xd4, last one becomes >> SC_CURSOR_CHAR) can be redefined with "vidcontrol -M", it is needed for >> the case they overlap valid characters region for some code tables. > > I didn't forget it, but these

Re: svn commit: r316642 - head/sys/dev/syscons

On 09.04.2017 7:54, Andrey Chernov wrote: > On 08.04.2017 13:00, Bruce Evans wrote: >> Log: >> Quick fix for removal of the mouse cursor in vga direct graphics modes >> (that is, in all supported 8, 15, 16 and 24-color modes). Moving the >> mouse cursor while ho

Re: svn commit: r316642 - head/sys/dev/syscons

On 08.04.2017 13:00, Bruce Evans wrote: > Log: > Quick fix for removal of the mouse cursor in vga direct graphics modes > (that is, in all supported 8, 15, 16 and 24-color modes). Moving the > mouse cursor while holding down a button (giving cut marking) left a > trail of garbage from

Re: svn commit: r316477 - head/usr.bin/grep

On 04.04.2017 16:41, Kyle Evans wrote: > Upon further review, newer versions of GNU grep(1) drop the explicit > '00' and add the \33[K dropped in this commit a few lines above the > mentioned one. In that case, we might as well revert those two lines and > consider this an improvement. I guess it

Re: svn commit: r316477 - head/usr.bin/grep

On 04.04.2017 16:05, Bruce Evans wrote: > This might be to work around a bug in a terminal driver. I needed the > 0 (but just one) to reset the attributes in my attribute tests, on at > least 1 of the tested terminals (current sc, current vt, old sc, old > xterm, old cygwin xterm). CSI m seems

Re: svn commit: r316477 - head/usr.bin/grep

33[00m as defined by ANSI. Of course we must handle (and already handle) both according to ANSI, but few CPU cycles here, then in another place, yet another, etc. making big time in sum when CPU does nothing useful but resource eating. > On Tue, Apr 4, 2017 at 7:37 AM, Andrey Chernov <a...@freebsd

Re: svn commit: r316477 - head/usr.bin/grep

On 04.04.2017 15:24, Kyle Evans wrote: > On Tue, Apr 4, 2017 at 7:07 AM, Andrey Chernov <a...@freebsd.org > <mailto:a...@freebsd.org>> wrote: > > On 04.04.2017 2:16, Ed Maste wrote: > > if (color) > > -

Re: svn commit: r316477 - head/usr.bin/grep

On 04.04.2017 2:16, Ed Maste wrote: > if (color) > - fprintf(stdout, "\33[m\33[K"); > + fprintf(stdout, "\33[00m\33[K"); Please back that one out. We don't need to handle internally or print remotely excessive 00. At

Re: svn commit: r316069 - in stable/10: contrib/ntp contrib/ntp/adjtimed contrib/ntp/clockstuff contrib/ntp/html contrib/ntp/include contrib/ntp/include/isc contrib/ntp/kernel contrib/ntp/kernel/sys c

On 28.03.2017 7:48, Xin LI wrote: > Author: delphij > Date: Tue Mar 28 04:48:55 2017 > New Revision: 316069 > URL: https://svnweb.freebsd.org/changeset/base/316069 > > Log: > MFC r315871: MFV r315791: ntp 4.2.8p10. Should /etc/ntp.conf be updated to?

Re: svn commit: r310433 - head/lib/libc/stdio

On 23.12.2016 1:39, Conrad Meyer wrote: > This was unjustified and inappropriate. I don't think so. While being able to back it out or fix it by another way by yourself, you just doing nothing for several days. Your personal reasons of inability to act properly so long time weights less than

Re: svn commit: r306294 - stable/10/sys/compat/linux

On 24.09.2016 13:34, Dmitry Chagin wrote: > Author: dchagin > Date: Sat Sep 24 10:34:35 2016 > New Revision: 306294 > URL: https://svnweb.freebsd.org/changeset/base/306294 > > Log: > MFC r305896: > > Implement BLKSSZGET ioctl for the Linuxulator. Off topic: is there any chance to get

Re: svn commit: r305981 - head/usr.bin/cmp

On 19.09.2016 19:13, Conrad E. Meyer wrote: > + /* > + * Cache NLS data, for strerror, for err(3), before entering capability > + * mode. > + */ > + (void)catopen("libc", NL_CAT_LOCALE); This code should be common for all programs which use err(), perror() etc. since they

Re: svn commit: r304928 - in head/lib/libc: amd64/sys i386/sys sys

On 29.08.2016 22:10, Konstantin Belousov wrote: > On Mon, Aug 29, 2016 at 09:16:29PM +0300, Andrey Chernov wrote: >> Previous text is documented everywhere and describing usual good >> practice, so it should remains in place, in that means r304928 should be >> reverted, becau

Re: svn commit: r304928 - in head/lib/libc: amd64/sys i386/sys sys

On 29.08.2016 21:16, Andrey Chernov wrote: > On 29.08.2016 21:04, Konstantin Belousov wrote: >> On Mon, Aug 29, 2016 at 08:46:47PM +0300, Andrey Chernov wrote: >>> Either we implement this wrapper or left all things as is, we need to >>> document internal errno clearin

Re: svn commit: r304928 - in head/lib/libc: amd64/sys i386/sys sys

On 29.08.2016 21:04, Konstantin Belousov wrote: > On Mon, Aug 29, 2016 at 08:46:47PM +0300, Andrey Chernov wrote: >> Either we implement this wrapper or left all things as is, we need to >> document internal errno clearing additionally, to not make people wonder >> why errn

Re: svn commit: r304928 - in head/lib/libc: amd64/sys i386/sys sys

On 29.08.2016 19:51, John Baldwin wrote: >> int >> ptrace(int request, pid_t pid, caddr_t addr, int data) >> { >> >> errno = 0; >> return (__sys_ptrace(request, pid, addr, data)); >> } > > Certainly I think having a C wrapper like this makes more sense than > doing it all in assembly N

Re: svn commit: r304928 - in head/lib/libc: amd64/sys i386/sys sys

On 29.08.2016 18:34, Konstantin Belousov wrote: > On Mon, Aug 29, 2016 at 06:05:50PM +0300, Andrey Chernov wrote: >> No surprise since they all share the same initial implementation. You >> can add NetBSD and OpenBSD too. Errno clearing as undocumented side >> effect is not wh

Re: svn commit: r304928 - in head/lib/libc: amd64/sys i386/sys sys

On 29.08.2016 10:07, Konstantin Belousov wrote: > On Mon, Aug 29, 2016 at 09:58:13AM +0300, Konstantin Belousov wrote: >> On Sun, Aug 28, 2016 at 04:09:51PM -0700, John Baldwin wrote: >>> OTOH, given that we explicitly documented it as not being true, I suspect >>> any applications that are using

Re: svn commit: r304928 - in head/lib/libc: amd64/sys i386/sys sys

On 28.08.2016 8:28, Bruce Evans wrote: >> How hard it will be to bring ptrace() to what C99 expects? Perhaps now >> time is suited well to change some obsoleted things. > > This should be safe to change, since portable applications like gdb can't > assume that the implemementation clobbers errno

Re: svn commit: r304928 - in head/lib/libc: amd64/sys i386/sys sys

On 28.08.2016 5:33, Andrey Chernov wrote: > "conforming implementation may have extensions (including additional > library functions), provided they do not alter the behavior of any > strictly conforming program.3)" > > ptrace() is extension (additional library function)

Re: svn commit: r304928 - in head/lib/libc: amd64/sys i386/sys sys

On 28.08.2016 4:52, Konstantin Belousov wrote: POSIX: "For each thread of a process, the value of errno shall not be affected by function calls or assignments to errno by other threads." >>> And ? What should the citation add new to the substance >>> of the code change ? >> >> This is

Re: svn commit: r304928 - in head/lib/libc: amd64/sys i386/sys sys

On 28.08.2016 4:37, Andrey Chernov wrote: > On 28.08.2016 4:25, Andrey Chernov wrote: >>> Point me to a single line in C99 which mentions ptrace(). > > Already done: ptrace == "any library function". To elaborate it more, C99 does not have finite list of library

Re: svn commit: r304928 - in head/lib/libc: amd64/sys i386/sys sys

On 28.08.2016 4:25, Andrey Chernov wrote: >> Point me to a single line in C99 which mentions ptrace(). Already done: ptrace == "any library function". ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/list

Re: svn commit: r304928 - in head/lib/libc: amd64/sys i386/sys sys

On 28.08.2016 4:15, Konstantin Belousov wrote: >> POSIX: "No function in this volume of POSIX.1-2008 shall set errno to zero." > I am quite curious where ptrace(2) is defined by POSIX. POSIX just repeats C99 statement for its own functions, supporting this rule too, but C99 rule is more general

Re: svn commit: r304928 - in head/lib/libc: amd64/sys i386/sys sys

On 28.08.2016 4:04, Andrey Chernov wrote: > On 28.08.2016 3:56, Konstantin Belousov wrote: >> On Sun, Aug 28, 2016 at 03:38:10AM +0300, Andrey Chernov wrote: >>> On 28.08.2016 2:03, Konstantin Belousov wrote: >>>> Since ptrace(2) syscall can return -1

Re: svn commit: r304928 - in head/lib/libc: amd64/sys i386/sys sys

On 28.08.2016 3:56, Konstantin Belousov wrote: > On Sun, Aug 28, 2016 at 03:38:10AM +0300, Andrey Chernov wrote: >> On 28.08.2016 2:03, Konstantin Belousov wrote: >>> Since ptrace(2) syscall can return -1 for non-error situations, libc >>> wrappers set errno to 0 be

Re: svn commit: r304928 - in head/lib/libc: amd64/sys i386/sys sys

On 28.08.2016 3:38, Andrey Chernov wrote: > On 28.08.2016 2:03, Konstantin Belousov wrote: >> Since ptrace(2) syscall can return -1 for non-error situations, libc >> wrappers set errno to 0 before performing the syscall, as the service >> to the caller. > >

Re: svn commit: r304928 - in head/lib/libc: amd64/sys i386/sys sys

On 28.08.2016 2:03, Konstantin Belousov wrote: > Since ptrace(2) syscall can return -1 for non-error situations, libc > wrappers set errno to 0 before performing the syscall, as the service > to the caller. Both C99 and POSIX directly prohibits any standard function to set errno to 0.

Re: svn commit: r304911 - head/lib/libc/net

On 27.08.2016 20:37, Brooks Davis wrote: > On Sat, Aug 27, 2016 at 02:43:13PM +, Andrey A. Chernov wrote: >> Author: ache >> Date: Sat Aug 27 14:43:13 2016 >> New Revision: 304911 >> URL: https://svnweb.freebsd.org/changeset/base/304911 >> >> Log: >> The formal behavior of qsort is unstable

Re: svn commit: r304781 - head/etc/rc.d

On 25.08.2016 5:58, Cy Schubert wrote: > Author: cy > Date: Thu Aug 25 02:58:41 2016 > New Revision: 304781 > URL: https://svnweb.freebsd.org/changeset/base/304781 > > Log: > Add logic to replace the working ntp leap-seconds file in /var/db > if it contains a $FreeBSD$ header. The header will

Re: svn commit: r304703 - head/include/xlocale

On 23.08.2016 23:53, Ngie Cooper (yaneurabeya) wrote: > >> On Aug 23, 2016, at 13:33, Andrey A. Chernov wrote: >> >> Author: ache >> Date: Tue Aug 23 20:33:56 2016 >> New Revision: 304703 >> URL: https://svnweb.freebsd.org/changeset/base/304703 >> >> Log: >> LC_*_MASK bit

Re: svn commit: r303716 - head/crypto/openssh

On 08.08.2016 1:48, Xin Li wrote: > Well, despite the fact that I have to admit that I get locked out from > my own storage box too, however (even without wearing any hat) I am for > the change and would blame myself for being lazy in adopting the change > when the upstream have announced it

Re: svn commit: r303716 - head/crypto/openssh

On 08.08.2016 2:01, Andrey Chernov wrote: > On 08.08.2016 1:48, Xin Li wrote: >> Well, despite the fact that I have to admit that I get locked out from >> my own storage box too, however (even without wearing any hat) I am for >> the change and would blame myself for b

Re: svn commit: r303716 - head/crypto/openssh

On 08.08.2016 0:28, Andrey Chernov wrote: > On 08.08.2016 0:20, Warner Losh wrote: >> >>> On Aug 7, 2016, at 3:11 PM, Andrey Chernov <a...@freebsd.org> wrote: >>> >>>> OTOH, FreeBSD has a documented deprecation process that says things will >>

Re: svn commit: r303716 - head/crypto/openssh

On 08.08.2016 0:20, Warner Losh wrote: > >> On Aug 7, 2016, at 3:11 PM, Andrey Chernov <a...@freebsd.org> wrote: >> >>> OTOH, FreeBSD has a documented deprecation process that says things will >>> continue working for a major release after bein

Re: svn commit: r303716 - head/crypto/openssh

On 07.08.2016 23:40, Peter Jeremy wrote: > On 2016-Aug-07 15:25:54 +0300, Andrey Chernov <a...@freebsd.org> wrote: >> You should address your complains to original openssh author instead, it >> was his decision to get rid of weak algos. > > No. It's up to the p

Re: svn commit: r303716 - head/crypto/openssh

On 07.08.2016 22:56, Slawa Olhovchenkov wrote: > On Sun, Aug 07, 2016 at 10:42:56PM +0300, Andrey Chernov wrote: > >> On 07.08.2016 22:10, Slawa Olhovchenkov wrote: >>> On Sun, Aug 07, 2016 at 10:02:52PM +0300, Andrey Chernov wrote: >>> >>>> On

Re: svn commit: r303716 - head/crypto/openssh

On 07.08.2016 22:10, Slawa Olhovchenkov wrote: > On Sun, Aug 07, 2016 at 10:02:52PM +0300, Andrey Chernov wrote: > >> On 07.08.2016 21:52, Slawa Olhovchenkov wrote: >>>> Why you still not >>>> send your opinion to the author? >>>> >>> >

Re: svn commit: r303716 - head/crypto/openssh

On 07.08.2016 21:52, Slawa Olhovchenkov wrote: >> Why you still not >> send your opinion to the author? >> > > I am not sure about suitable response from autor. > May be project [FreeBSD] choise some compromise. IMHO blindly choosing some compromise without asking author's opinion first will be

Re: svn commit: r303716 - head/crypto/openssh

On 07.08.2016 21:23, Slawa Olhovchenkov wrote: > On Sun, Aug 07, 2016 at 09:06:37PM +0300, Andrey Chernov wrote: > >> On 07.08.2016 20:43, Andrey Chernov wrote: >>> On 07.08.2016 20:37, Slawa Olhovchenkov wrote: >>>> On Sun, Aug 07, 2016 at 08:34

Re: svn commit: r303716 - head/crypto/openssh

On 07.08.2016 20:43, Andrey Chernov wrote: > On 07.08.2016 20:37, Slawa Olhovchenkov wrote: >> On Sun, Aug 07, 2016 at 08:34:55PM +0300, Andrey Chernov wrote: >> >>> On 07.08.2016 20:31, Andrey Chernov wrote: >>>> On 07.08.2016 19:14, Bruce Simpson wrote: >&g

Re: svn commit: r303716 - head/crypto/openssh

On 07.08.2016 20:37, Slawa Olhovchenkov wrote: > On Sun, Aug 07, 2016 at 08:34:55PM +0300, Andrey Chernov wrote: > >> On 07.08.2016 20:31, Andrey Chernov wrote: >>> On 07.08.2016 19:14, Bruce Simpson wrote: >>>> On 07/08/16 15:40, Warner Losh wrote: >>>&g

Re: svn commit: r303716 - head/crypto/openssh

On 07.08.2016 19:14, Bruce Simpson wrote: > On 07/08/16 15:40, Warner Losh wrote: >> That’s a cop-out answer. We, as a project, need to articulate to our >> users, whom we care about, why this rather obnoxious hit to usability >> was taken. The answer must be more complete than “We just disabled

Re: svn commit: r303716 - head/crypto/openssh

On 07.08.2016 20:31, Andrey Chernov wrote: > On 07.08.2016 19:14, Bruce Simpson wrote: >> On 07/08/16 15:40, Warner Losh wrote: >>> That’s a cop-out answer. We, as a project, need to articulate to our >>> users, whom we care about, why this rather obnoxious hit

Re: svn commit: r303716 - head/crypto/openssh

On 07.08.2016 20:31, Andrey Chernov wrote: > On 07.08.2016 19:14, Bruce Simpson wrote: >> On 07/08/16 15:40, Warner Losh wrote: >>> That’s a cop-out answer. We, as a project, need to articulate to our >>> users, whom we care about, why this rather obnoxious hit

Re: svn commit: r303716 - head/crypto/openssh

On 07.08.2016 17:40, Warner Losh wrote: > >> On Aug 7, 2016, at 7:21 AM, Andrey Chernov <a...@freebsd.org> wrote: >>> >>>> We can't turn our security >>>> team into compatibility team, by constantly restoring removed code, such >>>>

Re: svn commit: r303716 - head/crypto/openssh

On 07.08.2016 15:52, Slawa Olhovchenkov wrote: >> You should address your complains to original openssh author instead, it >> was his decision to get rid of weak algos. In my personal opinion, if >> your hardware is outdated, just drop it out. > > Hardware outdated by outdated main function, not

Re: svn commit: r303716 - head/crypto/openssh

On 07.08.2016 14:59, Bruce Simpson wrote: > On 07/08/16 12:43, Oliver Pinter wrote: >>> I was able to override this (somewhat unilateral, to my mind) >>> deprecation of the DH key exchange by using this option: >>> -oKexAlgorithms=+diffie-hellman-group1-sha1 >> >> You can add this option to

Re: svn commit: r303264 - head/usr.bin/calendar/calendars/ru_RU.UTF-8

On 02.08.2016 12:26, Gleb Smirnoff wrote: > You got your own commit access now, so please do it yourself if you > are confident enough about the change. I am not :) Really this date is in the middle, see http://bibliopskov.ru/4november.htm ___

Re: svn commit: r303530 - head/lib/libc/gen

On 30.07.2016 11:52, Bruce Evans wrote: > On Sat, 30 Jul 2016, Andrey Chernov wrote: > >> On 30.07.2016 7:15, Bruce Evans wrote: >>> On Sat, 30 Jul 2016, Andrey A. Chernov wrote: >>> >>>> Log: >>>> Reset errno for readdirfunc() before contunu

Re: svn commit: r303530 - head/lib/libc/gen

On 30.07.2016 7:15, Bruce Evans wrote: > On Sat, 30 Jul 2016, Andrey A. Chernov wrote: > >> Log: >> Reset errno for readdirfunc() before contunue. > > In C99, library functions are not permitted to set errno to 0. The glob() > family shouldn't use a different (worse) convention, and POSIX

Re: svn commit: r303354 - head/share/timedef

On 27.07.2016 3:46, Kevin Lo wrote: > Author: kevlo > Date: Wed Jul 27 00:46:48 2016 > New Revision: 303354 > URL: https://svnweb.freebsd.org/changeset/base/303354 > > Log: > Add weekday to the date format. This file is generated, so this change will be lost after next generation. It will be

Re: svn commit: r303218 - head/tools/tools/locale/tools

On 23.07.2016 15:32, Baptiste Daroussin wrote: > On Sat, Jul 23, 2016 at 02:58:31PM +0300, Andrey Chernov wrote: >> On 23.07.2016 14:52, Baptiste Daroussin wrote: >>> On Sat, Jul 23, 2016 at 02:41:39PM +0300, Andrey Chernov wrote: >>>> On 23.07.2016 14:24, Baptiste

Re: svn commit: r303264 - head/usr.bin/calendar/calendars/ru_RU.UTF-8

What happens with the lines below? On 24.07.2016 13:35, Gleb Smirnoff wrote: > Modified: head/usr.bin/calendar/calendars/ru_RU.UTF-8/calendar.orthodox > -Пасха-7 Вход Господень в Иерусалим. Вербное Воскресенье > +Пасха-7 Вход Господень в Иерусалим. Вербное Воскресент.ье > +Пасха

Re: svn commit: r303218 - head/tools/tools/locale/tools

On 23.07.2016 14:52, Baptiste Daroussin wrote: > On Sat, Jul 23, 2016 at 02:41:39PM +0300, Andrey Chernov wrote: >> On 23.07.2016 14:24, Baptiste Daroussin wrote: >>> Author: bapt >>> Date: Sat Jul 23 11:24:05 2016 >>> New Revision: 303218 >>> URL: htt

Re: svn commit: r303218 - head/tools/tools/locale/tools

On 23.07.2016 14:24, Baptiste Daroussin wrote: > Author: bapt > Date: Sat Jul 23 11:24:05 2016 > New Revision: 303218 > URL: https://svnweb.freebsd.org/changeset/base/303218 > > Log: > Add another hack to add weekday to date format to more locales > > While here only initialize the iconv

Re: svn commit: r302601 - in head/sys: arm/include arm64/include

On 12.07.2016 11:35, Andrew Turner wrote: > On Tue, 12 Jul 2016 00:37:48 + (UTC) > "Andrey A. Chernov" wrote: > >> Author: ache >> Date: Tue Jul 12 00:37:48 2016 >> New Revision: 302601 >> URL: https://svnweb.freebsd.org/changeset/base/302601 >> >> Log: >> I don't know

Re: svn commit: r302026 - in head: share/monetdef share/msgdef share/numericdef share/timedef tools/tools/locale/tools

On 21.06.2016 10:12, Baptiste Daroussin wrote: > On Mon, Jun 20, 2016 at 10:14:04PM +0300, Andrey Chernov wrote: >> On 20.06.2016 9:45, Baptiste Daroussin wrote: >>> Author: bapt >>> Date: Mon Jun 20 06:45:42 2016 >>> New Revision: 302026 >>> URL: htt

Re: svn commit: r302026 - in head: share/monetdef share/msgdef share/numericdef share/timedef tools/tools/locale/tools

On 20.06.2016 9:45, Baptiste Daroussin wrote: > Author: bapt > Date: Mon Jun 20 06:45:42 2016 > New Revision: 302026 > URL: https://svnweb.freebsd.org/changeset/base/302026 > > Log: > Fix generation of locales with multiple variants Thanx. Just want to note, even if we stay with RFC 5646

Re: svn commit: r302016 - in head: share/timedef tools/tools/locale/tools

On 19.06.2016 22:40, Baptiste Daroussin wrote: > On Sun, Jun 19, 2016 at 10:02:26PM +0300, Andrey Chernov wrote: >> On 19.06.2016 20:21, Andrey Chernov wrote: >>> On 19.06.2016 20:10, Baptiste Daroussin wrote: >>>> On Sun, Jun 19, 2016 at 08:05:30PM +0300, Andrey Cher

Re: svn commit: r302016 - in head: share/timedef tools/tools/locale/tools

On 19.06.2016 20:21, Andrey Chernov wrote: > On 19.06.2016 20:10, Baptiste Daroussin wrote: >> On Sun, Jun 19, 2016 at 08:05:30PM +0300, Andrey Chernov wrote: >>> On 19.06.2016 19:52, Andrey Chernov wrote: >>>> On 19.06.2016 19:47, Andrey Chernov wrote: >&

Re: svn commit: r302016 - in head: share/timedef tools/tools/locale/tools

On 19.06.2016 20:10, Baptiste Daroussin wrote: > On Sun, Jun 19, 2016 at 08:05:30PM +0300, Andrey Chernov wrote: >> On 19.06.2016 19:52, Andrey Chernov wrote: >>> On 19.06.2016 19:47, Andrey Chernov wrote: >>>> On 19.06.2016 18:49, Baptiste Daroussin wrote: >>&g

Re: svn commit: r302016 - in head: share/timedef tools/tools/locale/tools

On 19.06.2016 20:05, Baptiste Daroussin wrote: > On Sun, Jun 19, 2016 at 07:47:27PM +0300, Andrey Chernov wrote: >> On 19.06.2016 18:49, Baptiste Daroussin wrote: >>> On Sun, Jun 19, 2016 at 04:52:34PM +0200, Baptiste Daroussin wrote: >>>> On Sun, Jun 19, 2016 at 07

Re: svn commit: r302016 - in head: share/timedef tools/tools/locale/tools

On 19.06.2016 19:52, Andrey Chernov wrote: > On 19.06.2016 19:47, Andrey Chernov wrote: >> On 19.06.2016 18:49, Baptiste Daroussin wrote: >>> On Sun, Jun 19, 2016 at 04:52:34PM +0200, Baptiste Daroussin wrote: >>>> On Sun, Jun 19, 2016 at 07:57:49AM +0300, Andrey Cher

Re: svn commit: r302016 - in head: share/timedef tools/tools/locale/tools

On 19.06.2016 18:49, Baptiste Daroussin wrote: > On Sun, Jun 19, 2016 at 04:52:34PM +0200, Baptiste Daroussin wrote: >> On Sun, Jun 19, 2016 at 07:57:49AM +0300, Andrey Chernov wrote: >>> On 19.06.2016 6:44, Hajimu UMEMOTO wrote: >>>> Log: >>>>

Re: svn commit: r302016 - in head: share/timedef tools/tools/locale/tools

On 19.06.2016 19:47, Andrey Chernov wrote: > On 19.06.2016 18:49, Baptiste Daroussin wrote: >> On Sun, Jun 19, 2016 at 04:52:34PM +0200, Baptiste Daroussin wrote: >>> On Sun, Jun 19, 2016 at 07:57:49AM +0300, Andrey Chernov wrote: >>>> On 19.06.2016 6:44, H

Re: svn commit: r302016 - in head: share/timedef tools/tools/locale/tools

On 19.06.2016 8:31, Hajimu UMEMOTO wrote: > Hi, > >>>>>> On Sun, 19 Jun 2016 07:57:49 +0300 >>>>>> Andrey Chernov <a...@freebsd.org> said: > > ache> Nonsense doubled formats in sr_*_RS locales and nonsense md_order there > too. >

Re: svn commit: r302016 - in head: share/timedef tools/tools/locale/tools

On 19.06.2016 6:44, Hajimu UMEMOTO wrote: > Log: > - Prefer to use %d over %e where the day of the month should be zero > filled. > - Since %e means the day of the month as well, regard %e as same as %d > in md_order. Nonsense doubled formats in sr_*_RS locales and nonsense md_order

Re: svn commit: r301777 - head/lib/libc/stdio

On 10.06.2016 17:14, Pedro Giffuni wrote: >> Because now strcoll_l() is used as before and it is broken in wide char >> converting process. It is broken for _all_, not just for vfscanf() >> ranges. It should never fail with any args. >> Real fix should be in strcoll_l(). >> > > Yes, it is broken

Re: svn commit: r301777 - head/lib/libc/stdio

On 10.06.2016 15:03, Pedro Giffuni wrote: > (Sorry I have been offline/sleep for a while) > > Hello; > > I cannot back this out because of this report: > > http://docs.freebsd.org/cgi/mid.cgi?20160608132224.GA15454 > > This change only re-states what has been working before the ABI breakage >

Re: svn commit: r301777 - head/lib/libc/stdio

Please back it out. __sccl() use plain chars, you can't just call wide chars __wcollate_range_cmp() from it. Never intermix plain chars and wide chars without conversion. The problem is somewhere else. The code used for [a-z] ranges in the format. Moreover, even if conversion added this code can't

Re: svn commit: r301577 - stable/10/etc/periodic/daily

The code still is called only if $daily_ntpd_leapfile_enable is YES and it is NO by default. On 08.06.2016 6:08, Cy Schubert wrote: > Author: cy > Date: Wed Jun 8 03:08:37 2016 > New Revision: 301577 > URL: https://svnweb.freebsd.org/changeset/base/301577 > > Log: > MFC r301102: > >

Re: svn commit: r301226 - in head: etc etc/defaults etc/periodic/security etc/rc.d lib lib/libblacklist libexec libexec/blacklistd-helper share/mk tools/build/mk usr.sbin usr.sbin/blacklistctl usr.sbi

On 06.06.2016 20:52, Slawa Olhovchenkov wrote: >> BTW, it is good idea: to check first, is supported firewall enabled, and >> only then enable blacklistd by default. > > What purpose? SUDDENLY lockout access to own host after some mistake > in password? I agree that default 1 day locking is too

Re: svn commit: r301226 - in head: etc etc/defaults etc/periodic/security etc/rc.d lib lib/libblacklist libexec libexec/blacklistd-helper share/mk tools/build/mk usr.sbin usr.sbin/blacklistctl usr.sbi

On 06.06.2016 20:22, Ian Lepore wrote: > On Mon, 2016-06-06 at 20:06 +0300, Andrey Chernov wrote: >> As variant, I keep hope blacklist sh helper will teach about ipfw >> soon, >> it looks possible. Then it can be re-enabled by default. > > No, it should still not be

Re: svn commit: r301226 - in head: etc etc/defaults etc/periodic/security etc/rc.d lib lib/libblacklist libexec libexec/blacklistd-helper share/mk tools/build/mk usr.sbin usr.sbin/blacklistctl usr.sbi

On 06.06.2016 20:00, Ian Lepore wrote: > Probably everyone assumed (like I did) that it would be disabled by > default, and didn't notice that wasn't the case. Your response > indicates the problem with "default enabled"... you mention enabling > packet filtering in pf.conf, my response is: WTF

Re: svn commit: r301461 - in head/lib/libc: gen locale regex

On 05.06.2016 22:12, Pedro F. Giffuni wrote: > When collation support was brought in, the second and third > arguments in __collate_range_cmp() were changed from int to > wchar_t, breaking the ABI. Change them to a "char" type which > makes more sense and keeps the ABI compatible. Not

Re: svn commit: r301461 - in head/lib/libc: gen locale regex

On 05.06.2016 22:12, Pedro F. Giffuni wrote: > --- head/lib/libc/regex/regcomp.c Sun Jun 5 18:16:33 2016 > (r301460) > +++ head/lib/libc/regex/regcomp.c Sun Jun 5 19:12:52 2016 > (r301461) > @@ -821,10 +821,10 @@ p_b_term(struct parse *p, cset *cs) >

Re: svn commit: r301277 - in head: . lib/clang lib/clang/include/clang/Basic lib/clang/libclangbasic

On 03.06.2016 20:44, Bryan Drewery wrote: > Thanks! > > I think this helps Andrey's recent clang rebuild issues as well since > the quite-common file was being touched often. Thanx! > > On 6/3/2016 9:17 AM, Dimitry Andric wrote: >> Author: dim >> Date: Fri Jun 3 16:17:36 2016 >> New Revision:

Re: svn commit: r300956 - head/lib/libc/stdlib

On 31.05.2016 17:17, Bruce Evans wrote: > Our rand should use just 1, and it is dangerous to change RAND_MAX again, > but can we even change the sequences? Something might depend on > reproducing the old sequences. This question already arises many times. The sequence must be reproducible during

Re: svn commit: r300956 - head/lib/libc/stdlib

This implementation of shifts 32-bit and 64-bit PRNGs looks more reliable than Mersenne primes and don't use Bignums: http://wwwmaths.anu.edu.au/~brent/ftp/random/xorgens305.tar.gz PDF article inside. On 31.05.2016 14:30, Andrey Chernov wrote: > On 31.05.2016 12:58, Bruce Evans wrote: >&g

Re: svn commit: r300956 - head/lib/libc/stdlib

On 31.05.2016 12:58, Bruce Evans wrote: > On Tue, 31 May 2016, Andrey Chernov wrote: > >> On 31.05.2016 9:48, Bruce Evans wrote: >>>> Perhaps you can find some ideas, answers and PRNG comparison in the >>>> original paper: >>>> http://www.firstpr.c

Re: svn commit: r300956 - head/lib/libc/stdlib

On 31.05.2016 9:48, Bruce Evans wrote: >> Perhaps you can find some ideas, answers and PRNG comparison in the >> original paper: >> http://www.firstpr.com.au/dsp/rand31/p1192-park.pdf > > The ones with Mersenne primes and tweaked Mersenne primes in the reference > (lanl?) given by pfg@ seem OK.

Re: svn commit: r300965 - head/lib/libc/stdlib

On 31.05.2016 8:53, Bruce Evans wrote: > On Tue, 31 May 2016, Andrey Chernov wrote: > >> On 31.05.2016 6:42, Bruce Evans wrote: >>> >>> Er, I already said which types are better -- [u]int_fast32_t here. >> >> [u]int_fast32_t have _at_least_ 32 bits. int

Re: svn commit: r300965 - head/lib/libc/stdlib

On 31.05.2016 6:42, Bruce Evans wrote: > > Er, I already said which types are better -- [u]int_fast32_t here. [u]int_fast32_t have _at_least_ 32 bits. int32_t in the initial PRNG can be changed since does not overflow and involve several calculations, but uint_fast32_t is needed just for two

Re: svn commit: r300965 - head/lib/libc/stdlib

On 30.05.2016 6:09, Bruce Evans wrote: > On Sun, 29 May 2016, Conrad Meyer wrote: > >> Does clang actually generate different code with this change? > > It should, on exotic arches. > >> On Sun, May 29, 2016 at 9:39 AM, Andrey A. Chernov >> wrote: >>> Log: >>> Micro

Re: svn commit: r300956 - head/lib/libc/stdlib

On 30.05.2016 5:17, Bruce Evans wrote: > On Sun, 29 May 2016, Andrey A. Chernov wrote: > >> Log: >> 1) Unifdef USE_WEAK_SEEDING since it is too obsolete to support and >> makes >> reading hard. > > Good. > >> 2) Instead of doing range transformation in each and every function >> here, >> do

Re: svn commit: r300965 - head/lib/libc/stdlib

On 29.05.2016 22:39, Conrad Meyer wrote: > Does clang actually generate different code with this change? Yes, without -O it generates andl$2147483647, ... With -O nothing is changed. In general, it can be not clang and I see no point to left junk code in any case. > > On Sun, May 29, 2016

Re: svn commit: r300377 - head/sys/compat/ndis

On 22.05.2016 3:06, Bruce Evans wrote: > On Sat, 21 May 2016, Pedro Giffuni wrote: > >> On 05/21/16 16:55, Conrad Meyer wrote: >>> On Sat, May 21, 2016 at 1:40 PM, Pedro Giffuni wrote: On 05/21/16 14:05, Conrad Meyer wrote: > Won't this still return a

Re: svn commit: r300384 - head/sys/compat/ndis

On 22.05.2016 3:29, Pedro F. Giffuni wrote: > static void > srand(unsigned int seed) > { > > + if (seed == 0) > + seed = 1; > srandom(seed); > } IMHO it is not needed. srandom() already handles seed == 0 case, there is no point to remap it to another constant.

Re: svn commit: r298367 - head/lib/libc/locale

On 21.04.2016 9:29, Baptiste Daroussin wrote: Modified: head/lib/libc/locale/ascii.c == --- head/lib/libc/locale/ascii.c Wed Apr 20 20:43:05 2016 (r298366) +++

Re: svn commit: r298367 - head/lib/libc/locale

On 21.04.2016 3:57, Andrey Chernov wrote: > On 20.04.2016 23:44, Baptiste Daroussin wrote: >> Author: bapt >> Date: Wed Apr 20 20:44:30 2016 >> New Revision: 298367 >> URL: https://svnweb.freebsd.org/changeset/base/298367 >> >> Log: >> Check

Re: svn commit: r298367 - head/lib/libc/locale

On 20.04.2016 23:44, Baptiste Daroussin wrote: > Author: bapt > Date: Wed Apr 20 20:44:30 2016 > New Revision: 298367 > URL: https://svnweb.freebsd.org/changeset/base/298367 > > Log: > Check the returned value of memchr(3) before using it > > Reported by:Coverity > CID:

Re: svn commit: r297407 - head/lib/libc/stdio

On 30.03.2016 4:32, Pedro F. Giffuni wrote: > --- head/lib/libc/stdio/freopen.c Wed Mar 30 01:08:08 2016 > (r297406) > +++ head/lib/libc/stdio/freopen.c Wed Mar 30 01:32:08 2016 > (r297407) > @@ -66,7 +66,8 @@ freopen(const char * __restrict file, co > (void)

Re: svn commit: r297408 - head/lib/libc/stdio

On 30.03.2016 9:13, Pedro F. Giffuni wrote: >*/ > + sverrno = 0; > if (file == NULL) { It introduces the bug of touching errno. Previous code does it right because 'goto finish;' can't happen with (f < 0) where errno is restored later. The whole errno code is complex here for

Re: svn commit: r294981 - in stable/10/sys/boot: common efi efi/boot1 efi/include efi/libefi efi/loader efi/loader/arch/amd64 fdt i386/libi386

On 30.01.2016 2:36, Andrey Chernov wrote: > I am not sure this is exact commit which cause this, but any operation > in /sys/boot/efi ends like this (by hand, not from buildworld): > (i386-stable machine, clang compiler) > > ===> efi (obj) > make[1]: "/usr/src/sys

Re: svn commit: r294981 - in stable/10/sys/boot: common efi efi/boot1 efi/include efi/libefi efi/loader efi/loader/arch/amd64 fdt i386/libi386

I am not sure this is exact commit which cause this, but any operation in /sys/boot/efi ends like this (by hand, not from buildworld): (i386-stable machine, clang compiler) ===> efi (obj) make[1]: "/usr/src/sys/boot/efi/Makefile" line 4: Malformed conditional (${COMPILER_TYPE} != "gcc") make[1]:

Re: svn commit: r292823 - in stable/10/sys: conf netinet

On 28.12.2015 6:15, Patrick Kelsey wrote: > This is explained in the top comment in sys/netinet/tcp_fastopen.c, but > I will repeat it here and elaborate a little. It is disabled by default > in the kernel build as a conservative measure until it is exercised more > widely, given the

  1   2   3   4   >