Re: ixl and BOOTP
On 2015-5-18, at 19:22, Ryan Stone ryst...@gmail.com wrote: Hm, I'm unable to reproduce this on the latest -CURRENT (r283059). My hardware is a little different from yours -- my CPU is a Haswell Xeon, and I have only 1 igb port and no ixgbe. Also, I was just booting GENERIC. I didn't have Xen or anything running. Happens also without Xen. I will dig a bit further. Thanks for testing! Lars signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [RFC] Replace gnu groff in base by heirloom doctools
On Sat, May 16, 2015 at 01:42:26AM +0200, Julian H. Stacey wrote: Hi Bapt current@ I think keeping a fully functionnal roff(7) toolchain part of the base system is very good on a unix. Yes, Unix has always also been a tool to get jobs done (aka PWB), as well as merely recompile more Unix. Ditto FreeBSD. From what I could check I cannot find any regression when migrating from gnu groff to heirloom doctools, if there is a particular area when you think extra care is needed please share it. Heirloom doctools: https://github.com/n-t-roff/heirloom-doctools Regression tests that use public BSD source data to build more BSD are a good start, but just a start, insufficient to discover all problems. There's non public user data sets to consider. Many users won't read current@, just announce@, so before removal hits a Release, we need a one Release warning, ie This is the last Release before old functionality goes. Assume lots of user data will Not be compatible with heirloom-doctools users wont know to start checking their data, until they see an announcement in the next Release. Those users would be able to use groff from ports and then have the benefit of a more up to date version of groff and a groff with more functionnality than the castrated version we do have in base while compatible. We'll need a copy of same version of existing tools, macros etc, copied out unchanged to a port or meta port so users affected have a lifeboat. groff is already in ports. User data Will break: (My groff usage frequently broke when groff changed: I use groff for CV, business card, letters, invoices, personal, with embedded pics, scaled offset figures, tables, fonts, sizes, ouput in all of txt ps pdf pcl html output.) Solved by using groff from ports. Unfortnately I have'nt time to help test with my data as FreeBSD already eats too much time, shoving bind from src to ports (+planning to dump bind move on) + ripping majordomo acroread out of ports, all of which I need must restore before upgrading servers workstations. Changes would need maximal warning minimum disruption please. Groff in base is rottening for various reasons and lacks lots of the features provided by a full groff. Using groff from ports is a win for user realying on groff specific toolchain. Heirloom in base is a win over groff because it has better support for roff(7) better font handling etc. Best regards, Bapt pgpVQk6eIduim.pgp Description: PGP signature
Build failed in Jenkins: FreeBSD_HEAD_i386 #160
See https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/160/changes Changes: [hiren] Add a new sysctl net.inet.tcp.hostcache.purgenow=1 to expire and purge all entries in hostcache immediately. In collaboration with: bz, rwatson MFC after: 1 week Relnotes: yes Sponsored by: Limelight Networks -- [...truncated 81174 lines...] rm -f .depend CC='cc ' mkdep -f .depend -a -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/clang/libclangast/../../../contrib/llvm/include -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/clang/libclangast/../../../contrib/llvm/tools/clang/include -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST -I. -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/clang/libclangast/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_STATIC_ANALYZER -DLLVM_DEFAULT_TARGET_TRIPLE=\i386-unknown-freebsd11.0\ -DLLVM_HOST_TRIPLE=\i386-unknown-freebsd11.0\ -DDEFAULT_SYSROOT=\\ -std=c++11 -stdlib=libc++ https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/APValue.cpp https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/clan g/libclangast/../../../contrib/llvm/tools/clang/lib/AST/ASTConsumer.cpp https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/ASTContext.cpp https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/ASTDiagnostic.cpp https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/ASTDumper.cpp https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/ASTImporter.cpp https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/ASTTypeTraits.cpp https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/AttrImpl.cpp https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AS T/CXXInheritance.cpp https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/Comment.cpp https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/CommentBriefParser.cpp https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/CommentCommandTraits.cpp https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/CommentLexer.cpp https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/CommentParser.cpp https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/CommentSema.cpp https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/Decl.cpp https://jenkins.freeb sd.org/job/FreeBSD_HEAD_i386/ws/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/DeclBase.cpp https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/DeclCXX.cpp https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/DeclFriend.cpp https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/DeclGroup.cpp https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/DeclObjC.cpp https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/DeclOpenMP.cpp https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/DeclPrinter.cpp https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/clang/libclangast/../../../con trib/llvm/tools/clang/lib/AST/DeclTemplate.cpp https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/DeclarationName.cpp https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/Expr.cpp https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/ExprCXX.cpp https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/ExprClassification.cpp
[283136]: buildworld failure: usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lproc
Current sources (r283136) die on buildworld with the following error: [...] --- cddl/lib__L --- /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lproc cc: error: linker command failed with exit code 1 (use -v to see invocation) *** [libdtrace.so.2] Error code 1 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Build failed in Jenkins: FreeBSD_HEAD_i386 #159
See https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/159/changes Changes: [bapt] Reduce overlinking. Because of libdtrace there is still a bit a overlinking but nothing we can deal with easily [bapt] Correctly link libdtrace and convert to LIBADD Make dtrace only link to libdtrace [bapt] Fix underlinking [bapt] Register libdtrace and its direct and indirect dependencies Register librdlt_db Register libproc dependencies Register libctf dependencies [bapt] Convert to LIBADD [bapt] Convert to LIBADD Remove dependency on pthread, it is not needed [imp] Re-select the SD card before getting the SD status. On a couple Atmel boards, this prevents some error messages during enumeration and also gives us the correct erase block size. They appear to be harmless elsewhere. # Note: we treat too many commands as 'can't fail' if they don't work # after a couple of retries. We need to fix that, but not today... [imp] Add NFS server to mix (for easier, in-place updates). Move to partition 2 for root (since partition 1 is reserved for FAT files the Atmel ROMs can load). [imp] Improve comment about unmapped I/O and fix typos. Submitted by: Matteo Riondato MFC After: 2 days [emaste] All FreeBSD platforms are elf: move i386-elf to i386 This was a leftover from when we had both i386 a.out and ELF. Reviewed by:kib, imp Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D2591 -- [...truncated 79472 lines...] --- lib__L --- --- depend_subdir_libedit --- === lib/libedit (depend) --- common.h --- sh https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/libedit/makelist -h https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/libedit/common.c common.h --- emacs.h --- sh https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/libedit/makelist -h https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/libedit/emacs.c emacs.h --- help.h --- sh https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/libedit/makelist -bh https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/libedit/vi.c https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/libedit/emacs.c https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/libedit/common.c help.h --- vi.h --- sh https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/libedit/makelist -h https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/libedit/vi.c vi.h --- depend_subdir_clang --- --- depend_subdir_libclangast --- === lib/clang/libclangast (depend) --- AttrImpl.inc.h --- clang-tblgen -gen-clang-attr-impl -I https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/clang/libclangast/../../../contrib/llvm/tools/clang/include -d AttrImpl.inc.d -o AttrImpl.inc.h https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/clang/libclangast/../../../contrib/llvm/tools/clang/include/clang/Basic/Attr.td --- depend_subdir_libedit --- --- historyn.c --- sh https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/lib/libedit/makelist -n history.c historyn.c --- cddl/lib__L --- --- dt_strtab.o --- cc -O2 -pipe -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/obj/jenkins/workspace/FreeBSD_HEAD_i386/cddl/lib/libdtrace -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/cddl/lib/libdtrace -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/cddl/lib/libdtrace/../../../sys/cddl/dev/dtrace/i386 -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/cddl/lib/libdtrace/../../../sys/cddl/compat/opensolaris -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/cddl/lib/libdtrace/../../../cddl/compat/opensolaris/include -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/head -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libctf/common -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/cddl/lib/lib dtrace/../../../sys/cddl/contrib/opensolaris/uts/common -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/cddl/lib/libdtrace/../../../sys/cddl/dev/dtrace/x86 -Ihttps://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/intel -DDIS_MEM -DNEED_SOLARIS_BOOLEAN -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknown-pragmas -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c https://jenkins.freebsd.org/job/FreeBSD_HEAD_i386/ws/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_strtab.c -o dt_strtab.o --- lib__L --- --- _sub.depend --- ===
Build failed in Jenkins: FreeBSD_HEAD-tests2 #1043
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/1043/ -- Started by upstream project Build_Image_and_Run_Tests_in_Bhyve_HEAD build number 1089 originally caused by: Started by upstream project FreeBSD_HEAD build number 2777 originally caused by: Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Building remotely on havoc.ysv.freebsd.org (FreeBSD-CURRENT-baremetal) in workspace https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/ws/ [FreeBSD_HEAD-tests2] $ /bin/sh -xe /tmp/hudson7273775553950966696.sh + sudo python /vm/freebsd-ci/scripts/test/run-tests.py -f /vm/freebsd-ci/scripts/test/config/config.json bhyveload -m 2G -d /net/jenkins-10.freebsd.org/builds/Build-UFS-image/image/FreeBSD_HEAD/test.img vm_test Consoles: userboot FreeBSD/amd64 User boot, Revision 1.1 (r...@havoc.ysv.freebsd.org, Sat Mar 7 06:40:36 UTC 2015) |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|Loading /boot/defaults/loader.conf /-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-[H[J\|/-\| [7;46H ````[8;46Hs` `.---...--.``` -/[9;46H+o .--` /y:` +.[10;46H yo`:.:o `+-[11;46H y/ -/` -o/[12;46H .- ::/sy+:.[13;46H / `-- /[14;46H`: :`[15;46H`: :`[16;46H / /[17;46H .--.[18;46H -- -.[19;46H `:` `:`[20;46H .-- `--.[21;46H .---../-\| [1;2H __ _ _ [2;2H| | | _ \ / | __ \ [3;2H| |___ _ __ ___ ___ | |_) | (___ | | | |[4;2H| ___| '__/ _ \/ _ \| _ \___ \| | | |[5;2H| | | | | __/ __/| |_) |) | |__| |[6;2H| | | | |||| | | |[7;2H|_| |_| \___|\___||/|_/|_/ [10;2H|[11;2H|[12;2H|[13;2H|[14;2H|[15;2H|[16;2H|[17;2H|[18;2H|[19;2H|[20;2H|[21;2H|[10;44H|[11;44H|[12;44H|[13;44H|[14;44H|[15;44H|[16;44H|[17;44H|[18;44H|[19;44H|[20;44H|[21;44H|[9;3H=[22;3H=[9;2H+[22;2H+[9;44H+[22;44H+[25;0H/-\|/-\|/-[9;15HWelcome to FreeBSD[11;5H1 [11;6H.[11;8HBoot Multi User [Enter][12;5H2 [12;6H.[12;8HBoot [S]ingle User[13;5H3 [13;6H.[13;8H[Esc]ape to loader prompt[14;5H4 [14;6H.[14;8HReboot[16;5HOptions:[17;5H5 [17;6H.[17;8H[K]ernel: kernel (1 of 2)[18;5H6 [18;6H.[18;8HConfigure Boot [O]ptions...[25;0H[23;4HAutoboot in 9 seconds. [Space] to pause[25;0H[23;4HAutoboot in 8 seconds. [Space] to pause[25;0H[23;4HAutoboot in 7 seconds. [Space] to pause[25;0H[23;4HAutoboot in 6 seconds. [Space] to pause[25;0H[23;4HAutoboot in 5 seconds. [Space] to pause[2 5;0H[23;4HAutoboot in 4 seconds. [Space] to pause[25;0H[23;4HAutoboot in 3 seconds. [Space] to pause[25;0H[23;4HAutoboot in 2 seconds. [Space] to pause[25;0H[23;4HAutoboot in 1 seconds. [Space] to pause[25;0H[23;4H [25;0H\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-/boot/kernel/kernel text=0x105cb30 \|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|Traceback (most recent call last): File /vm/freebsd-ci/scripts/test/run-tests.py, line 152, in module main(sys.argv) File /vm/freebsd-ci/scripts/test/run-tests.py, line 80, in main runTest() File /vm/freebsd-ci/scripts/test/run-tests.py, line 96, in runTest child.expect(pexpect.EOF) File /usr/local/lib/python2.7/site-packages/pexpect/__init__.py, line 1451, in expect timeout, searchwindowsize) File /usr/local/lib/python2.7/site-packages/pexpect/__init__.py, line 1466, in expect_list timeout, searchwindowsize) File /usr/local/lib/python2.7/site-packages/pexpect/__init__.py, line 1568, in expect_loop raise TIMEOUT(str(err) + '\n' + str(self)) pexpect.TIMEOUT: Timeout exceeded. pexpect.spawn object at 0x803eeba50 version: 3.3 command: /usr/sbin/bhyveload args: [u'/usr/sbin/bhyveload', u'-m', u'2G', u'-d', u'/net/jenkins-10.freebsd.org/builds/Build-UFS-image/image/FreeBSD_HEAD/test.img', u'vm_test'] searcher: pexpect.searcher_re object at 0x803eeba10 buffer (last 100 chars):
Re: [RFC] Replace gnu groff in base by heirloom doctools
Baptiste Daroussin b...@freebsd.org wrote: |On Sat, May 16, 2015 at 01:42:26AM +0200, Julian H. Stacey wrote: | I think keeping a fully functionnal roff(7) toolchain part of the | base system is very good on a unix. | From what I could check I cannot find any regression when \ | migrating from gnu | groff to heirloom doctools, if there is a particular area \ | when you think extra | care is needed please share it. It seems you haven't checked at all. It seems to me that e.g. mdoc(7) of n-t-r seems to require quite a bit of work in order to be at all usable. |Heirloom in base is a win over groff because it has better \ |support for roff(7) |better font handling etc. The macros i use for myself don't work with n-t-r, too: once i truly looked (a few months ago) i found that i would have to rewrite all traps and other positioning in order to get that right. Despite that you seem to do what you want to do anyway, n-t-r is possibly a usable troff, if you go its way and deal with it you may be able to gain a bit nicer output _faster_ and without converting your beloved special fonts first, but in no way is n-t-r a _replacement_ for groff. Ciao, --steffen ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Aw: Re: [RFC] Replace gnu groff in base by heirloom doctools
Steffen Nurpmeso sdao...@yandex.com wrote: It seems you haven't checked at all. It seems to me that e.g. mdoc(7) of n-t-r seems to require quite a bit of work in order to be at all usable. This is not completely true. It is usable, I did check it with all about 7000 manpages in the base of OpenBSD. But it does indeed also require further work. Please note that FreeBSD uses mandoc(1) for formatting manpages. Groff in the base (or a replacement) is only a fallback. The macros i use for myself don't work with n-t-r, too: once i truly looked (a few months ago) i found that i would have to rewrite all traps and other positioning in order to get that right. Please make a bug report ;) Despite that you seem to do what you want to do anyway, n-t-r is possibly a usable troff, if you go its way and deal with it you may be able to gain a bit nicer output _faster_ and without converting your beloved special fonts first, but in no way is n-t-r a _replacement_ for groff. The groff version in the base is quite old and is there to have a *roff toolchain in the base and as a fallback solution for mandoc(1). If one does serious typesetting (and wants to use groff) it is recommended to use the up-to-date version from ports. Carsten ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] Replace gnu groff in base by heirloom doctools
On Tue, May 19, 2015 at 02:37:22PM +0200, Steffen Nurpmeso wrote: Baptiste Daroussin b...@freebsd.org wrote: |On Sat, May 16, 2015 at 01:42:26AM +0200, Julian H. Stacey wrote: | I think keeping a fully functionnal roff(7) toolchain part of the | base system is very good on a unix. | From what I could check I cannot find any regression when \ | migrating from gnu | groff to heirloom doctools, if there is a particular area \ | when you think extra | care is needed please share it. It seems you haven't checked at all. It seems to me that e.g. mdoc(7) of n-t-r seems to require quite a bit of work in order to be at all usable. Lots of work has been done recently on heirloom in particular regarding the support of mdoc(7) and I have opened tickets for all issues I could find and they have been fixed. Please point me to issues you can have regarding mdoc(7). (Note that I'm speaking of doctools as of latest git, not latest release) |Heirloom in base is a win over groff because it has better \ |support for roff(7) |better font handling etc. The macros i use for myself don't work with n-t-r, too: once i truly looked (a few months ago) i found that i would have to rewrite all traps and other positioning in order to get that right. Can you tell me more about the macros you do use and a sample document so I can check and see if we can add support for it? Despite that you seem to do what you want to do anyway, n-t-r is possibly a usable troff, if you go its way and deal with it you may be able to gain a bit nicer output _faster_ and without converting your beloved special fonts first, but in no way is n-t-r a _replacement_ for groff. As I said you will be able to use groff from ports. I do not claim that n-t-r is a replacement for groff in general I propose it for a replacement for groff in base. groff in base is stuck at 1.19.2 version while upstream is at 1.22.3 version which in particular has a couple of fixes for mdoc(7) format and a bit more. Every user of groff will have huge benefit using newer groff versions: bug fixes, full functionnalities available etc. Best regards, Bapt pgp8dJYKiJyrI.pgp Description: PGP signature
pedantic compiler warnings: double semicolons, function to data pointers
While trying to compile some of my (kernel) code in different environments, i noticed a couple of errors that perhaps might be worth fixing - extra semicolons. These come either from explicit repetitions in the code (see the output of a grep at the end of this message), or sometimes from the epansion of macros such as BITSET_DEFINE() - conversion between function and data pointers. One is in mbuf.h m-m_ext.ext_free = m-m_ext.ext_arg1 = m-m_ext.ext_arg2 = NULL; Shuold we care/bother to fix these as we step through them ? cheers luigi crypto/openssh/openbsd-compat/bsd-cray.c: debug(Setting MLS labels.);; crypto/heimdal/appl/telnet/libtelnet/encrypt.c:buflen -= 2;; crypto/heimdal/lib/krb5/aes-test.c: continue;; crypto/heimdal/lib/krb5/aes-test.c: continue;; crypto/heimdal/lib/hdb/hdb-ldap.c: bv[i] = ber_memalloc(sizeof(**bv));; crypto/heimdal/lib/hx509/print.c: \teku-%d: %s\n, i, str);; crypto/openssl/engines/ccgost/gostsum.c:int failcount = 0, count = 0;; crypto/openssl/apps/ca.c:BIO_printf(bio_err, Type :%s\n, p);; crypto/openssl/apps/s_client.c:sbuf_len -= i;; crypto/openssl/crypto/asn1/x_crl.c:break;; lib/libfetch/common.c: delta.tv_usec / 1000;; lib/libc/db/btree/bt_overflow.c:for (last = NULL, p = dbt-data, sz = dbt-size;; sbin/fsck_ffs/globs.c: bzero(startprog, sizeof(struct timespec));; sys/geom/label/g_label_msdosfs.c: for (offset = fat_BytesPerSector * fat_FirstDataSector;; sys/boot/arm/at91/libat91/sd-card.c:AT91C_BASE_PDC_MCI-PDC_RCR = SD_BLOCK_SIZE / 4;; sys/amd64/vmm/io/vlapic.c: return ((lapic-lvt_timer) + i);; sys/ofed/drivers/net/mlx4/en_tx.c: int frags = tx_info-nr_segs;; sys/ofed/drivers/infiniband/hw/mthca/mthca_provider.c: n = mr-umem-nmap;; sys/sys/systm.h:voidexplicit_bzero(void *, size_t) __nonnull(1);; sys/arm/arm/vm_machdep.c: td2-td_md.md_saved_cspr = PSR_SVC32_MODE;; sys/arm/arm/trap-v6.c: tf-tf_r0 = EFAULT;; sys/arm/amlogic/aml8726/aml8726_sdxc-m8.c: stop = start + 4;; sys/net80211/ieee80211_superg.c:error = ieee80211_parent_xmitpkt(ic, m);; sys/pc98/cbus/olpt.c: sc-sc_backoff = hz / LPTOUTINITIAL;; sys/contrib/dev/ath/ath_hal/ar9300/ar9300_reset.c: cl_tab_reg += 4;; sys/contrib/ipfilter/netinet/ip_state.c:hv += tcp-th_dport;; sys/contrib/ipfilter/netinet/ip_state.c:hv += tcp-th_sport;; sys/contrib/ipfilter/netinet/ip_frag.c: ipf_frag_softc_t *softf = softc-ipf_frag_soft;; sys/contrib/ngatm/netnatm/sig/sig_party.c: p-state = UNI_EPSTATE_NULL;; sys/cam/ctl/ctl.c: ctsio-kern_data_ptr = malloc(len, M_CTL, M_WAITOK);; sys/cam/ctl/ctl.c: ctsio-kern_data_ptr = malloc(len, M_CTL, M_WAITOK);; sys/cam/scsi/scsi_da.c: struct da_softc *softc = (struct da_softc *)periph-softc;; sys/cddl/dev/fbt/fbt.c: const Elf_Sym *symp = lc-symtab;; sys/cddl/dev/fbt/fbt.c: const ctf_header_t *hp = (const ctf_header_t *) lc-ctftab;; sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c: va+off, DMU_READ_PREFETCH);; sys/cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c:processorid_t cpu = 0;; sys/dev/stge/if_stge.c: for (cons = sc-sc_cdata.stge_tx_cons;; sys/dev/cxgbe/iw_cxgbe/mem.c:return ERR_PTR(-ENOMEM);; sys/dev/oce/oce_sysctl.c: pimg-img_offset = 13107200;; sys/dev/iscsi/iscsi.h: struct cv is_login_cv;; sys/dev/netmap/netmap_kern.h:void generic_rx_handler(struct ifnet *ifp, struct mbuf *m);; sys/dev/mpr/mpr_user.c: dir = BUS_DMASYNC_POSTWRITE;; sys/dev/hptnr/hptnr_os_bsd.c: return (HPT_U32)pci_cfgregread(bus, dev, func, reg, 4);; sys/dev/hyperv/netvsc/hv_net_vsc.c: netvsc_dev *net_dev = sc-net_dev;; sys/dev/hyperv/netvsc/hv_net_vsc.c: netvsc_dev *net_dev = sc-net_dev;; sys/dev/hyperv/netvsc/hv_net_vsc.c: netvsc_dev *net_dev = sc-net_dev;; sys/dev/netmap_new/netmap_kern.h:void generic_rx_handler(struct ifnet *ifp, struct mbuf *m);; sys/net/ieee8023ad_lacp.c: lp-lp_partner = lacp_partner_admin_optimistic;; tools/regression/rpcsec_gss/rpctest.c: gethostname(hostname, sizeof(hostname));; usr.sbin/fstyp/msdosfs.c: for (offset = fat_BytesPerSector * fat_FirstDataSector;; usr.sbin/ctladm/ctladm.c: char *max_data_segment_length;; usr.sbin/ctladm/ctladm.c: char *offload;; ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pedantic compiler warnings: double semicolons, function to data pointers
On 19 May 2015 at 11:42, Luigi Rizzo ri...@iet.unipi.it wrote: While trying to compile some of my (kernel) code in different environments, i noticed a couple of errors that perhaps might be worth fixing - extra semicolons. These come either from explicit repetitions in the code (see the output of a grep at the end of this message), or sometimes from the epansion of macros such as BITSET_DEFINE() I think removing double-semicolons isn't a bad task.. -a ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] Replace gnu groff in base by heirloom doctools
On Tue, May 19, 2015 at 06:52:40PM +0200, Steffen Nurpmeso wrote:
Hello,
Baptiste Daroussin b...@freebsd.org wrote:
|On Tue, May 19, 2015 at 02:37:22PM +0200, Steffen Nurpmeso wrote:
| Baptiste Daroussin b...@freebsd.org wrote:
||On Sat, May 16, 2015 at 01:42:26AM +0200, Julian H. Stacey wrote:
|
|| I think keeping a fully functionnal roff(7) toolchain part of the
|| base system is very good on a unix.
|
|| From what I could check I cannot find any regression when \
|| migrating from gnu
|| groff to heirloom doctools, if there is a particular area \
|| when you think extra
|| care is needed please share it.
|
| It seems you haven't checked at all.
| It seems to me that e.g. mdoc(7) of n-t-r seems to require quite
| a bit of work in order to be at all usable.
|
|Lots of work has been done recently on heirloom in particular regarding
|the support of mdoc(7) and I have opened tickets for all issues \
|I could find and
|they have been fixed. Please point me to issues you can have \
|regarding mdoc(7).
.Ns doesn't work right, so is why this strong emphasis of mine in
the first sentence. Carsten has this example of mine (last week):
.Dd Apr 30, 2015
.Dt xxx 1
.Os
.Sh NAME
.Nm xxx
.Nd yyy
.
Read the system mailbox of
.Ar user
(appropriate privileges presumed), and
.Dq assume to be
.Ar user
in some aspects, e.g. in respect to
.Ic file Ns
\(enexpansions of
.Ql %
etc.; also see
.Ev USER .
Thanks I will have a look at it soon
|(Note that I'm speaking of doctools as of latest git, not latest release)
As of last week right shortly after your mail i guess it was.
||Heirloom in base is a win over groff because it has better \
||support for roff(7)
||better font handling etc.
|
| The macros i use for myself don't work with n-t-r, too: once
| i truly looked (a few months ago) i found that i would have to
| rewrite all traps and other positioning in order to get that
| right.
|
|Can you tell me more about the macros you do use and a sample \
|document so I can
|check and see if we can add support for it?
Well Carsten asked me this too last year and i've given him as
much as i could. But the macros are really rather simple layout
via traps. If i recall correctly the examples i've shown Carsten
where letters. I would have to rewrite the macros before i can
make them public, but it is pretty normal troff stuff with
traps and positioning, like e.g. the context-free following, for
an example (i think i have sent Carsten some trap info back then?)
.MACRO RECEIVER
. S:BOOLIFY \\$1
. ie \\n[S:#IS_BOOL] \{\
. vs \\n(.su*\\*[RECEIVER_LINE_SPACING_SCALE_FACTOR]
. nf
. de S:RECEIVER_TRAP EOT
.blm PARA
.ds S:RECEIVER_DIVERSION_HOOK
.sp 1v
\\*[RECEIVER_PREHOOK]\c
.EOT
. di S:RECEIVER_DIVERSION
. blm S:RECEIVER_TRAP
. \}
. el \{\
. if d S:RECEIVER_DIVERSION_HOOK \{\
\\*[RECEIVER_POSTHOOK]\c
.rm S:RECEIVER_DIVERSION_HOOK
. \}
. di
. \ Calculate best position for address field and box out
. if (\\n(dnu \\n[#RECEIVER_HEIGHT]u) \{\
.WARNING \
\\$0 address does not fit in address window! Growing window!!
.nr #RECEIVER_HEIGHT \\n(dnu
. \}
. nr #1 (\\n[#RECEIVER_HEIGHT]u-\\n(dnu)/2u
. sp |(\\n[#RECEIVER_START]u+\\n(#1u
. rr #1
. S:RECEIVER_DIVERSION
. rm S:RECEIVER_DIVERSION
. rm S:RECEIVER_TRAP
. fi
. vs
. \}
..
Pretty clean letter stuff like that it is. (You asked for an
example.)
Same I'll have a look :)
| Despite that you seem to do what you want to do anyway, n-t-r is
| possibly a usable troff, if you go its way and deal with it you
| may be able to gain a bit nicer output _faster_ and without
| converting your beloved special fonts first, but in no way is
| n-t-r a _replacement_ for groff.
|
|As I said you will be able to use groff from ports. I do not \
I will have my own one, then. Enough work for getting old. d^.^b
|claim that n-t-r is
|a replacement for groff in general I propose it for a replacement \
|for groff in
|base.
|
|groff in base is stuck at 1.19.2 version while upstream is at 1.22.3 version
|which in particular has a couple of fixes for mdoc(7) format and a bit more.
The mdoc(7) macros are BSD licensed. Nothing prevents anyone from
taking those from GNU troff [master] branch and integrating them
into their own roff version. I did that for (the one that will
be) mine.
|Every user of groff will have huge benefit using newer groff versions: bug
|fixes, full functionnalities available etc.
The above macros originate from stuff written under FreeBSD 4.9
and especially 5.3 and ran almost a decade there, very smoothly.
Also i'm not so sure about that huge when i compare groff
Build failed in Jenkins: FreeBSD_HEAD-tests2 #1042
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/1042/ -- Started by upstream project Build_Image_and_Run_Tests_in_Bhyve_HEAD build number 1088 originally caused by: Started by upstream project FreeBSD_HEAD build number 2776 originally caused by: Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Building remotely on havoc.ysv.freebsd.org (FreeBSD-CURRENT-baremetal) in workspace https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/ws/ [FreeBSD_HEAD-tests2] $ /bin/sh -xe /tmp/hudson2846174843478439466.sh + sudo python /vm/freebsd-ci/scripts/test/run-tests.py -f /vm/freebsd-ci/scripts/test/config/config.json bhyveload -m 2G -d /net/jenkins-10.freebsd.org/builds/Build-UFS-image/image/FreeBSD_HEAD/test.img vm_test Consoles: userboot FreeBSD/amd64 User boot, Revision 1.1 (r...@havoc.ysv.freebsd.org, Sat Mar 7 06:40:36 UTC 2015) |/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|Loading /boot/defaults/loader.conf /-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-[H[J\|/-\| [7;46H ````[8;46Hs` `.---...--.``` -/[9;46H+o .--` /y:` +.[10;46H yo`:.:o `+-[11;46H y/ -/` -o/[12;46H .- ::/sy+:.[13;46H / `-- /[14;46H`: :`[15;46H`: :`[16;46H / /[17;46H .--.[18;46H -- -.[19;46H `:` `:`[20;46H .-- `--.[21;46H .---../-\| [1;2H __ _ _ [2;2H| | | _ \ / | __ \ [3;2H| |___ _ __ ___ ___ | |_) | (___ | | | |[4;2H| ___| '__/ _ \/ _ \| _ \___ \| | | |[5;2H| | | | | __/ __/| |_) |) | |__| |[6;2H| | | | |||| | | |[7;2H|_| |_| \___|\___||/|_/|_/ [10;2H|[11;2H|[12;2H|[13;2H|[14;2H|[15;2H|[16;2H|[17;2H|[18;2H|[19;2H|[20;2H|[21;2H|[10;44H|[11;44H|[12;44H|[13;44H|[14;44H|[15;44H|[16;44H|[17;44H|[18;44H|[19;44H|[20;44H|[21;44H|[9;3H=[22;3H=[9;2H+[22;2H+[9;44H+[22;44H+[25;0H/-\|/-\|/-[9;15HWelcome to FreeBSD[11;5H1 [11;6H.[11;8HBoot Multi User [Enter][12;5H2 [12;6H.[12;8HBoot [S]ingle User[13;5H3 [13;6H.[13;8H[Esc]ape to loader prompt[14;5H4 [14;6H.[14;8HReboot[16;5HOptions:[17;5H5 [17;6H.[17;8H[K]ernel: kernel (1 of 2)[18;5H6 [18;6H.[18;8HConfigure Boot [O]ptions...[25;0H[23;4HAutoboot in 9 seconds. [Space] to pause[25;0H[23;4HAutoboot in 8 seconds. [Space] to pause[25;0H[23;4HAutoboot in 7 seconds. [Space] to pause[25;0H[23;4HAutoboot in 6 seconds. [Space] to pause[25;0H[23;4HAutoboot in 5 seconds. [Space] to pause[2 5;0H[23;4HAutoboot in 4 seconds. [Space] to pause[25;0H[23;4HAutoboot in 3 seconds. [Space] to pause[25;0H[23;4HAutoboot in 2 seconds. [Space] to pause[25;0H[23;4HAutoboot in 1 seconds. [Space] to pause[25;0H[23;4H [25;0H\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-/boot/kernel/kernel text=0x105cad0 \|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/Traceback (most recent call last): File /vm/freebsd-ci/scripts/test/run-tests.py, line 152, in module main(sys.argv) File /vm/freebsd-ci/scripts/test/run-tests.py, line 80, in main runTest() File /vm/freebsd-ci/scripts/test/run-tests.py, line 96, in runTest child.expect(pexpect.EOF) File /usr/local/lib/python2.7/site-packages/pexpect/__init__.py, line 1451, in expect timeout, searchwindowsize) File /usr/local/lib/python2.7/site-packages/pexpect/__init__.py, line 1466, in expect_list timeout, searchwindowsize) File /usr/local/lib/python2.7/site-packages/pexpect/__init__.py, line 1568, in expect_loop raise TIMEOUT(str(err) + '\n' + str(self)) pexpect.TIMEOUT: Timeout exceeded. pexpect.spawn object at 0x803eeba50 version: 3.3 command: /usr/sbin/bhyveload args: [u'/usr/sbin/bhyveload', u'-m', u'2G', u'-d', u'/net/jenkins-10.freebsd.org/builds/Build-UFS-image/image/FreeBSD_HEAD/test.img', u'vm_test'] searcher: pexpect.searcher_re object at 0x803eeba10 buffer (last 100 chars):
Re: [RFC] Replace gnu groff in base by heirloom doctools
Hello,
Baptiste Daroussin b...@freebsd.org wrote:
|On Tue, May 19, 2015 at 02:37:22PM +0200, Steffen Nurpmeso wrote:
| Baptiste Daroussin b...@freebsd.org wrote:
||On Sat, May 16, 2015 at 01:42:26AM +0200, Julian H. Stacey wrote:
|
|| I think keeping a fully functionnal roff(7) toolchain part of the
|| base system is very good on a unix.
|
|| From what I could check I cannot find any regression when \
|| migrating from gnu
|| groff to heirloom doctools, if there is a particular area \
|| when you think extra
|| care is needed please share it.
|
| It seems you haven't checked at all.
| It seems to me that e.g. mdoc(7) of n-t-r seems to require quite
| a bit of work in order to be at all usable.
|
|Lots of work has been done recently on heirloom in particular regarding
|the support of mdoc(7) and I have opened tickets for all issues \
|I could find and
|they have been fixed. Please point me to issues you can have \
|regarding mdoc(7).
.Ns doesn't work right, so is why this strong emphasis of mine in
the first sentence. Carsten has this example of mine (last week):
.Dd Apr 30, 2015
.Dt xxx 1
.Os
.Sh NAME
.Nm xxx
.Nd yyy
.
Read the system mailbox of
.Ar user
(appropriate privileges presumed), and
.Dq assume to be
.Ar user
in some aspects, e.g. in respect to
.Ic file Ns
\(enexpansions of
.Ql %
etc.; also see
.Ev USER .
|(Note that I'm speaking of doctools as of latest git, not latest release)
As of last week right shortly after your mail i guess it was.
||Heirloom in base is a win over groff because it has better \
||support for roff(7)
||better font handling etc.
|
| The macros i use for myself don't work with n-t-r, too: once
| i truly looked (a few months ago) i found that i would have to
| rewrite all traps and other positioning in order to get that
| right.
|
|Can you tell me more about the macros you do use and a sample \
|document so I can
|check and see if we can add support for it?
Well Carsten asked me this too last year and i've given him as
much as i could. But the macros are really rather simple layout
via traps. If i recall correctly the examples i've shown Carsten
where letters. I would have to rewrite the macros before i can
make them public, but it is pretty normal troff stuff with
traps and positioning, like e.g. the context-free following, for
an example (i think i have sent Carsten some trap info back then?)
.MACRO RECEIVER
. S:BOOLIFY \\$1
. ie \\n[S:#IS_BOOL] \{\
. vs \\n(.su*\\*[RECEIVER_LINE_SPACING_SCALE_FACTOR]
. nf
. de S:RECEIVER_TRAP EOT
.blm PARA
.ds S:RECEIVER_DIVERSION_HOOK
.sp 1v
\\*[RECEIVER_PREHOOK]\c
.EOT
. di S:RECEIVER_DIVERSION
. blm S:RECEIVER_TRAP
. \}
. el \{\
. if d S:RECEIVER_DIVERSION_HOOK \{\
\\*[RECEIVER_POSTHOOK]\c
.rm S:RECEIVER_DIVERSION_HOOK
. \}
. di
. \ Calculate best position for address field and box out
. if (\\n(dnu \\n[#RECEIVER_HEIGHT]u) \{\
.WARNING \
\\$0 address does not fit in address window! Growing window!!
.nr #RECEIVER_HEIGHT \\n(dnu
. \}
. nr #1 (\\n[#RECEIVER_HEIGHT]u-\\n(dnu)/2u
. sp |(\\n[#RECEIVER_START]u+\\n(#1u
. rr #1
. S:RECEIVER_DIVERSION
. rm S:RECEIVER_DIVERSION
. rm S:RECEIVER_TRAP
. fi
. vs
. \}
..
Pretty clean letter stuff like that it is. (You asked for an
example.)
| Despite that you seem to do what you want to do anyway, n-t-r is
| possibly a usable troff, if you go its way and deal with it you
| may be able to gain a bit nicer output _faster_ and without
| converting your beloved special fonts first, but in no way is
| n-t-r a _replacement_ for groff.
|
|As I said you will be able to use groff from ports. I do not \
I will have my own one, then. Enough work for getting old. d^.^b
|claim that n-t-r is
|a replacement for groff in general I propose it for a replacement \
|for groff in
|base.
|
|groff in base is stuck at 1.19.2 version while upstream is at 1.22.3 version
|which in particular has a couple of fixes for mdoc(7) format and a bit more.
The mdoc(7) macros are BSD licensed. Nothing prevents anyone from
taking those from GNU troff [master] branch and integrating them
into their own roff version. I did that for (the one that will
be) mine.
|Every user of groff will have huge benefit using newer groff versions: bug
|fixes, full functionnalities available etc.
The above macros originate from stuff written under FreeBSD 4.9
and especially 5.3 and ran almost a decade there, very smoothly.
Also i'm not so sure about that huge when i compare groff
1.19.2-574-gecbf4f1 (which is the last GPL2 commit) and 1.22.3.
Also Carsten said that. Until now i have indeed assumed it is
purely rhetoric.
Out of interest: what do you mean when you say full
functionality? I see some improvements in the line breaking
algorithm and
Re: pedantic compiler warnings: double semicolons, function to data pointers
On Tue, 2015-05-19 at 11:56 -0700, Adrian Chadd wrote: On 19 May 2015 at 11:42, Luigi Rizzo ri...@iet.unipi.it wrote: While trying to compile some of my (kernel) code in different environments, i noticed a couple of errors that perhaps might be worth fixing - extra semicolons. These come either from explicit repetitions in the code (see the output of a grep at the end of this message), or sometimes from the epansion of macros such as BITSET_DEFINE() I think removing double-semicolons isn't a bad task.. As long as whoever does it also MFCs it so that it isn't just a bunch of lurking merge conflicts in the future. -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: pedantic compiler warnings: double semicolons, function to data pointers
On 05/19/2015 14:42, Luigi Rizzo wrote: While trying to compile some of my (kernel) code in different environments, i noticed a couple of errors that perhaps might be worth fixing - extra semicolons. These come either from explicit repetitions in the code (see the output of a grep at the end of this message), or sometimes from the epansion of macros such as BITSET_DEFINE() - conversion between function and data pointers. One is in mbuf.h m-m_ext.ext_free = m-m_ext.ext_arg1 = m-m_ext.ext_arg2 = NULL; Shuold we care/bother to fix these as we step through them ? I would say yes, since that would reduce the noise in the compiler warning output. I realize the warning could be disabled, but cleaning up the ~50 occurrences [of ;;] seems like the better way. Eric ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
