Re: svn commit: r261031 - in head: . etc usr.sbin/etcupdate usr.sbin/mergemaster

On 22 Jan 2014, at 22:36, Glen Barber g...@freebsd.org wrote: It needs to use the build host version, because using (for example) powerpc resulting binary won't work on and amd64 system. If it's used as part of the build, then it should be part of the toolchain target and we should be using

Re: svn commit: r273135 - in head/sys: contrib/rdma/krping dev/cxgbe/iw_cxgbe ofed/drivers/infiniband/core ofed/drivers/infiniband/hw/mlx4 ofed/drivers/infiniband/hw/mthca ofed/drivers/infiniband/ulp/

On 16 Oct 2014, at 14:41, Mateusz Guzik mjgu...@gmail.com wrote: Well, atomic_set can be as simple as v-counter = i; (which btw will make it look identical to linux version). This should not give any measureable effect unless atomic_set on given var is abused quite a lot. v-counter = i does

Re: svn commit: r273274 - head/sys/netpfil/ipfw

On 19 Oct 2014, at 13:02, Andriy Gapon a...@freebsd.org wrote: I think that on platforms where an optimized version of fls() is available that would work faster than this cool piece of bit magic. If you're lucky, the compiler's idiom recogniser will spot this. You're generally better off

Re: svn commit: r274086 - head/sbin/route

On 4 Nov 2014, at 10:28, Stefan Farfeleder stef...@freebsd.org wrote: Shouldn't Coverity understand that err doesn't return? err() is marked as __dead2, which expands to __attribute__((__noreturn__)). If Coverity doesn't know that __attribute__((__noreturn__)) functions don't return, then

Re: svn commit: r273382 - head/contrib/libcxxrt

On 6 Nov 2014, at 01:04, Rui Paulo rpa...@me.com wrote: I don't think the non-temporary fix was ever committed. What's the problem? Is something else defining these methods? Yes, they're defined by libc++ too. The problem is that gcc 4.9 wants to be able to throw bad_array_new_length

Re: svn commit: r274340 - in head/sys: crypto/rijndael dev/random geom/bde

On 11 Nov 2014, at 16:31, Brooks Davis bro...@freebsd.org wrote: In general, we need to fix the C/C++ standard to us express the things we actually mean when we use const (for example see strchr()'s use of const). I believe the last issue now being tracked on Google's internal list of

Re: svn commit: r274489 - in head/sys/amd64: amd64 include

On 21 Nov 2014, at 23:26, Scott Long scott4l...@yahoo.com wrote: That’s a good question to look further into. I didn’t see any measurable differences with this change. I think that the cost of the function call itself masks the cost of a few extra instructions, but I didn’t test with

Re: svn commit: r278479 - in head: etc sys/kern

On 10 Feb 2015, at 18:30, Rui Paulo rpa...@me.com wrote: Another thing I had in mind (which is more work) was to abstract the devctl kernel code in an API which could make it easy to fan out the notifications to multiple /dev devices. However, that may be overkill. This kind of

Re: svn commit: r279764 - head/sys/vm

On 10 Mar 2015, at 10:18, Konstantin Belousov kostik...@gmail.com wrote: Because you cannot grep for the panic string when __func__ is used. The userspace assert uses __func__, __FILE__ and __LINE__, which means that you never need to grep the source code to find out where the assert came

Re: svn commit: r279603 - in head: bin/rcp usr.bin/rlogin usr.bin/rsh

On 5 Mar 2015, at 14:04, Dmitry Sivachenko de...@freebsd.org wrote: It is so nice to have most useful stuff out of the box. The question is whether a tool for logging into remote machines without encryption is 'the most useful stuff'. The tool is also [ab]used for network testing, but we

Re: svn commit: r279603 - in head: bin/rcp usr.bin/rlogin usr.bin/rsh

On 5 Mar 2015, at 12:30, Slawa Olhovchenkov s...@zxy.spb.ru wrote: Yes, if ships before (don't break if working). Some Linux distro remove telnet from default install. Do you like to remove telnet also? Absolutely, now that netcat is part of the default install. For anything that a sane

Re: svn commit: r279603 - in head: bin/rcp usr.bin/rlogin usr.bin/rsh

On 5 Mar 2015, at 12:33, Slawa Olhovchenkov s...@zxy.spb.ru wrote: And how to test open/listing ports/sockets?! netcat - nc(1) - which can also work in the other direction and is designed specifically for this purpose. How to connect to mpd control socket?! mpdcon from the command line,

Re: svn commit: r279603 - in head: bin/rcp usr.bin/rlogin usr.bin/rsh

On 5 Mar 2015, at 12:21, Slawa Olhovchenkov s...@zxy.spb.ru wrote: I guess when they are going to be not precious enough to be removed? :) In modern world of ssh and https, does any OS require them in base? yes. Some telecom equipment require rlogin. 'Some relatively obscure use case

Re: svn commit: r279603 - in head: bin/rcp usr.bin/rlogin usr.bin/rsh

On 5 Mar 2015, at 14:13, Slawa Olhovchenkov s...@zxy.spb.ru wrote: Not better, no. Does telnet support creating server sockets? No. Does telnet support IPsec? No. Does telnet let you specify the tcp window size? No. Does telnet come with a massive selection of options for insecure login /

Re: svn commit: r279603 - in head: bin/rcp usr.bin/rlogin usr.bin/rsh

On 5 Mar 2015, at 13:14, Slawa Olhovchenkov s...@zxy.spb.ru wrote: In previos message -- silently return when telnet speak about used IP address and diagnostic messages. One simple command do many diagnostic information. Okay, so check the return code. Or pass -v if you want more verbose

Re: svn commit: r279603 - in head: bin/rcp usr.bin/rlogin usr.bin/rsh

On 5 Mar 2015, at 12:42, Slawa Olhovchenkov s...@zxy.spb.ru wrote: netcat - nc(1) - which can also work in the other direction and is designed specifically for this purpose. nc(1) don't correctly work. It works for me for everything that I used to use telnet for (connection testing,

Re: svn commit: r280955 - in head/sys: modules/notrandom dev/notrandom

On 2 Apr 2015, at 11:22, Mateusz Guzik mjgu...@gmail.com wrote: Now one has to wonder how obnoxious one has to get so that people think this can't be real. I tried really hard. :) Not sure about your locale, but here (where the tradition originated) if you fool someone in the morning then

Re: svn commit: r281721 - head/sys/sys

On 20 Apr 2015, at 17:19, Bruce Evans b...@optusnet.com.au wrote: Enums should never be used in ABIs, since their size can be anything large enough. The rules for the size of enums also differ between C and C++, though clang (and, I think, gcc) support an attribute for specifying the enum

svn commit: r281925 - head/lib/libc/locale

Author: theraven Date: Fri Apr 24 10:17:55 2015 New Revision: 281925 URL: https://svnweb.freebsd.org/changeset/base/281925 Log: Small changes to locale-related man pages. Fix a missing .h and change the recommended include for the POSIX2008 functions from xlocale.h to locale.h. Including

svn commit: r281927 - head/lib/libc/locale

Author: theraven Date: Fri Apr 24 10:21:20 2015 New Revision: 281927 URL: https://svnweb.freebsd.org/changeset/base/281927 Log: __xlocale_C_ctype should not be const. It contains a reference count that is modified by newlocale / duplocale / freelocale. MFC after:1 week Modified:

Re: svn commit: r280955 - in head/sys: modules/notrandom dev/notrandom

On 1 Apr 2015, at 18:41, Mateusz Guzik mjgu...@gmail.com wrote: I guess you were right, this was bad. I moved the implementation to null.c, I hope this makes everyone happy. https://lists.freebsd.org/pipermail/svn-src-all/2015-April/101876.html This almost certainly does not make people

Re: svn commit: r268137 - head/sys/sys

On 19 Jun 2015, at 14:41, Hans Petter Selasky h...@selasky.org wrote: On 06/19/15 14:54, David Chisnall wrote: I definitely know of people building out-of-ports programs on FreeBSD whose code you have just broken (including myself, though I do Objective-C stuff on 10, so haven’t yet

Re: svn commit: r268137 - head/sys/sys

On 19 Jun 2015, at 12:57, Hans Petter Selasky h...@selasky.org wrote: Hi, Then they will get a compile error no matter what GNUstep’s Foundation.h does. It can’t prevent cdefs.h from redefining __weak to be something different. Except #undef __weak” Please read the example that I

Re: svn commit: r268137 - head/sys/sys

I only just caught this (having seen the fallout from NetBSD doing the same thing in a shipping release and the pain that it’s caused): __weak is a reserved keyword in Objective-C, please pick another name for this. This in cdefs.h makes it impossible to include any FreeBSD standard headers in

Re: svn commit: r268137 - head/sys/sys

On 19 Jun 2015, at 11:45, Hans Petter Selasky h...@selasky.org wrote: Appearently this will be fixed in GNUSTEP base: http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/sys/cdefs_elf.h?only_with_tag=MAIN Is this still an issue? It is impossible to fix it in GNUstep Base, because we can’t

Re: svn commit: r268137 - head/sys/sys

On 19 Jun 2015, at 15:32, Marcelo Araujo araujobsdp...@gmail.com wrote: Maybe would be a good idea run an 'exp run' with this patch? Just to double check if any port will break, although after you rename, I don't believe it will conflict anymore, however an 'exp run' would show you it.

Re: svn commit: r284198 - head/bin/ls

On 13 Jun 2015, at 11:17, Ian Lepore i...@freebsd.org wrote: If you would have told me a year ago that you had a simple scheme that could make 30 years of experience maintaining code for unix-like systems completely worthless I would have been skeptical, but it seems we're well on our way.

Re: svn commit: r286715 - head/lib/libc/string

On 13 Aug 2015, at 08:56, Marcelo Araujo araujobsdp...@gmail.com wrote: So it means, this commit here was right already: https://svnweb.freebsd.org/base?view=revisionrevision=286651 Although I made a mistake with the date. More or less. I partly agree with Bruce that suggesting memcpy is

Re: svn commit: r286715 - head/lib/libc/string

On 13 Aug 2015, at 08:11, Marcelo Araujo araujobsdp...@gmail.com wrote: The bcopy() was removed in IEEE Std 1003.1-2008 and it is marked as LEGACY in IEEE Std 1003.1-2004. However, BSD has its implementation before IEEE Std 1003.1-2001. In my understood it is obsolete on POSIX, but not

Re: svn commit: r286168 - head/sys/net

On 2 Aug 2015, at 17:34, Ian Lepore i...@freebsd.org wrote: It generates a compiler error, so the output is going to contain file-and-line like any other compiler error, as well as the message from the source code. It will, of course, vary between compilers, but this is what clang generates:

Re: svn commit: r285552 - head/usr.bin/xargs

On 15 Jul 2015, at 01:02, Xin Li delp...@delphij.net wrote: My only concern with strtonum() is that it's English only. Given that strtonum() wraps strtoll, it ought to support whatever the current locale is (assuming that the program calls setlocale() before calling strtonum(), otherwise it

Re: svn commit: r289995 - head/usr.bin/dtc

On 26 Oct 2015, at 10:48, Baptiste Daroussin wrote: > > Just jumping on that one, you should probably revisit de HACKING files :) Ah, good point. I’ll update them. David ___ svn-src-head@freebsd.org mailing list

svn commit: r289996 - head/usr.bin/dtc

Author: theraven Date: Mon Oct 26 11:02:57 2015 New Revision: 289996 URL: https://svnweb.freebsd.org/changeset/base/289996 Log: Update some obsolete information in the HACKING document. Reported by: bapt Modified: head/usr.bin/dtc/HACKING Modified: head/usr.bin/dtc/HACKING

svn commit: r289995 - head/usr.bin/dtc

Author: theraven Date: Mon Oct 26 10:37:17 2015 New Revision: 289995 URL: https://svnweb.freebsd.org/changeset/base/289995 Log: Ensure that dtc is built in C++11 mode. Reported by: George Abdelmalik Modified: head/usr.bin/dtc/Makefile Modified: head/usr.bin/dtc/Makefile

svn commit: r289935 - in head/usr.bin: . dtc

Author: theraven Date: Sun Oct 25 14:52:16 2015 New Revision: 289935 URL: https://svnweb.freebsd.org/changeset/base/289935 Log: Lots of improvements to the BSD-licensed dtc - Various fixes to includes (including recursive includes) - Lots of testing that the output exactly matches GPL'd

Re: svn commit: r289027 - head/contrib/tzcode/stdtime

On 8 Oct 2015, at 13:51, Andriy Gapon wrote: > > What if one day github disappears but FreeBSD is still going? > The full commit message would be lost. That’s not the only thing that is bad about this commit message. Why ‘Assume C89?’ We compile libc as C99 + GNU extensions

Re: svn commit: r285284 - head/lib/liblzma

On 9 Jul 2015, at 03:53, NGie Cooper yaneurab...@gmail.com wrote: $ cat ~/has_immintrin.c #include sys/cdefs.h #if __has_include(immintrin.h) #error I have immintrin.h #else #error I don't have immintrin.h #endif $ clang -c ~/has_immintrin.c /home/ngie/has_immintrin.c:4:2: error: I

Re: svn commit: r285284 - head/lib/liblzma

On 9 Jul 2015, at 10:19, NGie Cooper yaneurab...@gmail.com wrote: Yes, but this case will fail for gcc 4.3 ~ 4.4 through 5.x if you use my recommended method... I think that’s probably fine. We basically have four cases that we care about: - People who are using clang because it’s the

Re: svn commit: r285404 - head/sys/compat/cloudabi

On 11 Jul 2015, at 21:56, Konstantin Belousov kostik...@gmail.com wrote: Bucket 2: The system call could also just fail and return an error (MSG_NOSIGPIPE). SIGPIPE exists to ensure that naive programs do something reasonable when their stdout suddenly goes away. Or, transposing the PoV, it

Re: svn commit: r290711 - head/sys/ofed/drivers/infiniband/core

On 13 Nov 2015, at 08:35, Konstantin Belousov wrote: > > On Fri, Nov 13, 2015 at 09:18:54AM +0100, Hans Petter Selasky wrote: >> Hi, >> >> On 11/12/15 18:17, Conrad Meyer wrote: >>> These should cast through (u)intptr_t rather than unsigned long. >>> >> >> This is Linux

Re: svn commit: r287780 - in head: share/man/man9 sys/kern sys/sys

On 17 Sep 2015, at 08:20, Hans Petter Selasky wrote: > > On 09/17/15 00:05, Gleb Smirnoff wrote: >> Weren't you explicitly asked not to touch this system without a proper >> review and discussion? > > Adding a new function is not touching code. Adding a new interface to an

svn commit: r292876 - head/usr.bin/dtc

Author: theraven Date: Tue Dec 29 16:29:42 2015 New Revision: 292876 URL: https://svnweb.freebsd.org/changeset/base/292876 Log: Improvements to BSD-licensed DTC. - Added an expression parser so that expressions from headers are now working - Fixed missing null terminators on cross

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

On 30 Dec 2015, at 00:48, Bruce Evans wrote: > > - C++ apparently spells this as both _Alignof() and alignof() after 2011/03 This is not correct. C++ spells it alignof. C spells it _Alignof, unless you include , in which case C spells it alignof and defines _

Re: svn commit: r295768 - head/usr.sbin/iostat

On 22 Feb 2016, at 10:15, Kubilay Kocak wrote: > > For the lay persons among us (I'm genuinely interested), what are the > the downsides to requiring initialization of all fields? Explicit initialisation, or initialisation in general? Being able to initialise the entire

Re: svn commit: r295768 - head/usr.sbin/iostat

On 19 Feb 2016, at 23:23, Dimitry Andric wrote: > > This warning is only produced when you use -Wall -W, and then initialize > structs partially, i.e. you initialize some fields but not others. I > think this is a quite reasonable warning for a high warning level. The warning

Re: svn commit: r302252 - head/sys/kern

On 4 Jul 2016, at 21:09, Adrian Chadd wrote: > > Right, so if we're not careful, we could leak bits of kernel memory, > and it can also screw up key cache comparisons. > > (I asked this question because I've been screwed by it recentlyish, > and it looks like the latest

Re: svn commit: r313040 - head/sys/mips/include

On 1 Feb 2017, at 08:13, Konstantin Belousov wrote: > > On Wed, Feb 01, 2017 at 10:38:42AM -0500, Alexander Kabaev wrote: >> On Wed, 1 Feb 2017 16:17:21 +0200 >> Konstantin Belousov wrote: >> >>> Please do not retry on sc failure, return the error to

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

On 16 Dec 2016, at 19:31, Baptiste Daroussin wrote: > > Other than that, it makes more difficult to use vanilla gcc with out userland. > and it is adding more complexity to be able to build freebsd from a non > freebsd > system which some people are working on. Why? You’ll

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

On 22 Dec 2016, at 23:02, Baptiste Daroussin wrote: > > I think it is pretty clear that there are too many people requesting the > revert > for the revert not to be done. Even if this feature is desired, the implementation in the patch is broken and should be reverted until

Re: svn commit: r323329 - head/sys/sys

On 8 Sep 2017, at 21:09, Mateusz Guzik wrote: > > Author: mjg > Date: Fri Sep 8 20:09:14 2017 > New Revision: 323329 > URL: https://svnweb.freebsd.org/changeset/base/323329 > > Log: > Allow __builtin_memset instead of bzero for small buffers of known size This change seems

svn commit: r323277 - head/lib/libc/locale

Author: theraven Date: Thu Sep 7 17:51:35 2017 New Revision: 323277 URL: https://svnweb.freebsd.org/changeset/base/323277 Log: Document some invariants for the XLC_ enum. These can't be reordered without breaking other code. Document that and add some static asserts to ensure that

Re: svn commit: r322875 - head/sys/dev/nvme

On 25 Aug 2017, at 07:32, Mark Millard wrote: > > As I remember _Static_assert is from C11, not > the older C99. In pre-C11 dialects of C, _Static_assert is an identifier reserved for the implementation. sys/cdefs.h defines it to generate a zero-length array if the

Re: svn commit: r326758 - in head/sys/i386: conf include

On 16 Dec 2017, at 18:05, John Baldwin wrote: > > When I build a FreeBSD/mips64 kernel with clang, > _any_ simple NFS op triggers a kernel stack overflow. Kernels compiled > with GCC do not. That is not my experience. I haven’t tried a MIPS64 kernel built with clang, but

Re: Deorbiting i386

On 25 May 2018, at 05:27, Maxim Sobolev wrote: > > The idea looks very inmature and short-sighted to me. i386 is here to stay > not as a server/desktop platform but as an embedded/low power/low cost > platform for at least 5-10 years to come. There are plenty of

Re: Deorbiting i386

On 26 May 2018, at 00:41, Maxim Sobolev wrote: > > If you've seen any of the atom bay trail systems in action you may understand > what I mean. You get full blown x64 system with four cores and it takes only > 2W of power. Which is pretty much my point - if you want a

Re: svn commit: r328159 - head/sys/modules

On 19 Jan 2018, at 05:07, Conrad Meyer wrote: > > The spec says the behavior is undefined; not that the compiler has to > produce a warning or error message. The compiler *does* get to > arbitrarily decide what it wants to do when it encounters UB. It is > wholly free to

<    1   2   3