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

[Steffen Nurpmeso]

Konstantin Belousov wrote in
 :
 |On Sat, Dec 19, 2020 at 02:52:25PM +0100, Steffen Nurpmeso wrote:
 |> Kevin Bowling wrote in
 |>  :
 |>|On Thu, Dec 17, 2020 at 9:33 AM Ian Lepore  wrote:
 |>|> On Thu, 2020-12-17 at 18:22 +0200, Konstantin Belousov wrote:
 |>|>> On Thu, Dec 17, 2020 at 01:01:01PM +, Jessica Clarke wrote:
 |>|>>> On 17 Dec 2020, at 12:53, Konstantin Belousov 
 |>|>>> wrote:
 |>|>>>> On Thu, Dec 17, 2020 at 12:41:47PM +, Mateusz Piotrowski
 |>|>>>> wrote:
 |>|>>>>> Author: 0mp (doc,ports committer)
 |>|>>>>> Date: Thu Dec 17 12:41:47 2020
 |>|>>>>> New Revision: 368714
 |>|>>>>> URL: https://svnweb.freebsd.org/changeset/base/368714
 |>  ...
 |>|>>>>> +   return (0);
 |>|>>>>
 |>|>>>> return (0) is redundand.
 |>  ...
 |>|>> Why it is bad practice ?
 |>|>>
 |>|>> C is a small language, and while knowing some quirks (like this one)
 |>|>> seems to be optional, others are not. And worse, that other quirks are
 |>  ...
 |>|> How obscure is this quirk?  I've been writing C code since 1983,
 |>|> including having released a freeware compiler (pre-gcc days) and
 |>|> working on a commercial C compiler.  I used to moderate the c_language
 |>|> conference on BIX (back when that was a thing).  I make my living
 |>|> writing C and C++ code every day.  And yet, I had completely forgotten
 |>|> about this quirk.
 |>  ...
 |>|In Kib’s defense I think this is commonly mentioned in C99 books \
 |>|(at least
 |>|that’s where I learned of it) so it depends on when and where someone
 |>|learned.  There are merits approaches of being explicit or brief.  I have
 |> 
 |> Nicely said.  K C 2nd Ed. explicitly uses return(0) many times.
 |
 |We are long after K in any of its form.
 |
 |My point was that the example if of very low quality, and return (0); is
 |an indicator.  Perhaps even more interesting point to make is the mix of
 |return from main() and exit(3) use in same 4 lines.  Besides inconsistency,
 |exit(3) from main() should probably not used in examples or recommended
 |to novices at all.

I .. cannot see this from the context above?

I personally use _?exit only if execution must not continue aka
control cannot be given back to code flow.
For me .. not.  C89 can be used here.  (It is annoying only for
field initializers, and there especially that the order must be
correct in C89 mode, when FIELD_INIT[IN]() expands to nothing.)

(Yes, one of the things i personally was out for was
restartability without leaks for at least development, ie, it was
only "fine" if one could have entered sf_main() multiple times
without causing problems.  This required "atexit_uninstall" and
two distinct priorities for exit handlers, and a clean order of
the "final" ones, also atcrash_uninstall, but it was nice to see
"SF: memcache empty!" messages in debug code, knowing it is nice.
Today i only do this a bit as i link other libraries anyway, and
everybody uses ctors and dtors and it is all dynamically linked,
.. and all that.)

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

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

[Steffen Nurpmeso]

Kevin Bowling wrote in
 :
 |On Thu, Dec 17, 2020 at 9:33 AM Ian Lepore  wrote:
 |> On Thu, 2020-12-17 at 18:22 +0200, Konstantin Belousov wrote:
 |>> On Thu, Dec 17, 2020 at 01:01:01PM +, Jessica Clarke wrote:
 |>>> On 17 Dec 2020, at 12:53, Konstantin Belousov 
 |>>> wrote:
 | On Thu, Dec 17, 2020 at 12:41:47PM +, Mateusz Piotrowski
 | wrote:
 |> Author: 0mp (doc,ports committer)
 |> Date: Thu Dec 17 12:41:47 2020
 |> New Revision: 368714
 |> URL: https://svnweb.freebsd.org/changeset/base/368714
 ...
 |> +   return (0);
 |
 | return (0) is redundand.
 ...
 |>> Why it is bad practice ?
 |>>
 |>> C is a small language, and while knowing some quirks (like this one)
 |>> seems to be optional, others are not. And worse, that other quirks are
 ...
 |> How obscure is this quirk?  I've been writing C code since 1983,
 |> including having released a freeware compiler (pre-gcc days) and
 |> working on a commercial C compiler.  I used to moderate the c_language
 |> conference on BIX (back when that was a thing).  I make my living
 |> writing C and C++ code every day.  And yet, I had completely forgotten
 |> about this quirk.
 ...
 |In Kib’s defense I think this is commonly mentioned in C99 books (at least
 |that’s where I learned of it) so it depends on when and where someone
 |learned.  There are merits approaches of being explicit or brief.  I have

Nicely said.  K C 2nd Ed. explicitly uses return(0) many times.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r367141 - head/usr.bin/fetch

[Steffen Nurpmeso]

Hey.

Fernando Apesteguía wrote in
 <202010291834.09tiylrb040...@repo.freebsd.org>:
 |Author: fernape (ports committer)
 |Date: Thu Oct 29 18:34:47 2020
 |New Revision: 367141
 |URL: https://svnweb.freebsd.org/changeset/base/367141
 |
 |Log:
 |  fetch(1): Add EXAMPLES section
 |  
 |  Add a few examples covering flags: 1, R, a, o, q, r, s, v
 |  
 |  Approved by:manpages (bcr@)
 |  Differential Revision:  https://reviews.freebsd.org/D26946
 |
 |Modified:
 |  head/usr.bin/fetch/fetch.1
 ...
 |+$ fetch -1 -q https://www.freebsd.org/bad.html \\
 |+ ftp.freebsd.org/pub/FreeBSD/README.TXT \\

groff(7) says

   \\ reduces  to  a single backslash; useful to delay its interpreta‐
  tion as escape character in copy mode.  For  a  printable  back‐
  slash,  use \e, or even better \[rs], to be independent from the
  current escape character.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r365984 - head/usr.bin/calendar/calendars

[Steffen Nurpmeso]

Ian Lepore wrote in
 <65448d226d8cf4318c1db49af993a14e54034dab.ca...@freebsd.org>:

 |And now you're arguing about the factual correctness of your comment in
 |reply to my comment which wasn't about the facts at all.
 |
 |Thank you for proving my point most elequently about why we should not
 |be purveyors of trivia or general knowledge.

Not true.  I even gave the suggestion to return to the original
calendar approach.
Furthermore everything should be taken with a grain of salt like
i think Warner Losh would say it, even if it comes from the
FreeBSD community.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r365984 - head/usr.bin/calendar/calendars

[Steffen Nurpmeso]

Ian Lepore wrote in
 :
 |On Tue, 2020-09-22 at 16:02 +0200, Steffen Nurpmeso wrote:
 |> Greg Lehey wrote in
 |>  <202009212255.08lmtpsp078...@repo.freebsd.org>:
 |>|Author: grog
 |>|Date: Mon Sep 21 22:55:51 2020
 |>|New Revision: 365984
 |>|URL: https://svnweb.freebsd.org/changeset/base/365984
 |>|
 |>|Log:
 |>|  Remove claim that Allied Forces created "West Germany" in
 |> 1953.  I can
 |>|  find no historic substantiation for such a claim.  The Federal
 |>|  Republic of Germany was created by Germans on 23 May 1949, as
 |> also
 |>|  noted in this file.
 |> 
 |> I could imagine it was Konrad Adenauer (chancellor at that time)
 |> refusing (let aside western war winners) the Sowjet offer to
 |> reunite Germany shall Germany henceforth exist as a "neutral
 |> state" in the same sense as Switzerland claims to be neutral.
 |> He refused, instead forward looking to rearm the German army.
 |> That is, turning Germany to a part of the Western Alliance
 |> explicitly and willingly.  Or was that in 1949?  Hm.
 |
 |And this is why I agree with Cy and Conrad that we should not be trying
 |to be wikipedia lite.

Not finding anything at all that is to say then?
On Wikipedia there is lobbyism and even war in big style for sure,
you can very often see this.
In fact, _this_ calendar entry is so fine because it mentions
something that is not talked about in Germany, the last time
i have heard it in the public was about twenty years ago, wait, it
was in fact 2003 during the German public law TV show "Greatest
Germans", and once the brave man said it ("sometimes the truth has
to be told") it came out how that audience was mounted, because
a loud LIE! could be heard.  And yes, Konrad Adenauer was
voted the greatest german of all time, a wise and comprehensible
decision, outperforming those dwarfs like Goethe, Schiller,
Beethoven, Einstein, Bach, and our wonderful emperor even.  I do
not understand!

The calendar program came into BSD in 1981 and originally only
looked for per user calendar files.
I am using this program ever since i started using FreeBSD, now
also on Linux.  Other than that i cannot help it, you know.
But it is great that just recently someone pimped the codebase in
order to make it work with other calendar formats also, i think.
(I cloned that specific repository in addition the second i read
the announcement.  Have not tried it yet though.  But will keep
it.)

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r365984 - head/usr.bin/calendar/calendars

[Steffen Nurpmeso]

Greg Lehey wrote in
 <202009212255.08lmtpsp078...@repo.freebsd.org>:
 |Author: grog
 |Date: Mon Sep 21 22:55:51 2020
 |New Revision: 365984
 ...
 |  head/usr.bin/calendar/calendars/calendar.history

By the way, on DragonFly there was a rewrite of the calendar(1)
program, it seems to have improved!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r365984 - head/usr.bin/calendar/calendars

[Steffen Nurpmeso]

Greg Lehey wrote in
 <202009212255.08lmtpsp078...@repo.freebsd.org>:
 |Author: grog
 |Date: Mon Sep 21 22:55:51 2020
 |New Revision: 365984
 |URL: https://svnweb.freebsd.org/changeset/base/365984
 |
 |Log:
 |  Remove claim that Allied Forces created "West Germany" in 1953.  I can
 |  find no historic substantiation for such a claim.  The Federal
 |  Republic of Germany was created by Germans on 23 May 1949, as also
 |  noted in this file.

I could imagine it was Konrad Adenauer (chancellor at that time)
refusing (let aside western war winners) the Sowjet offer to
reunite Germany shall Germany henceforth exist as a "neutral
state" in the same sense as Switzerland claims to be neutral.
He refused, instead forward looking to rearm the German army.
That is, turning Germany to a part of the Western Alliance
explicitly and willingly.  Or was that in 1949?  Hm.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r365836 - head/share/mk

[Steffen Nurpmeso]

Warner Losh wrote in
 :
 |On Thu, Sep 17, 2020, 11:25 AM Jessica Clarke  wrote:
 |>> On 17 Sep 2020, at 18:23, Jessica Clarke  wrote:
 |>>
 |>>> On 17 Sep 2020, at 18:05, Rodney W. Grimes 
 |> wrote:
 |>>>
 |>>>> On Thu, Sep 17, 2020 at 9:39 AM Steffen Nurpmeso 
 |> wrote:
 |>>>>
 |>>>>> Alex Richardson wrote in
 |>>>>> <202009171507.08hf7qns080...@repo.freebsd.org>:
 |>>>>>|Author: arichardson
 |>>>>>|Date: Thu Sep 17 15:07:25 2020
 |>>>>>|New Revision: 365836
 |>>>>>|URL: https://svnweb.freebsd.org/changeset/base/365836
 |>>>>>|
 |>>>>>|Log:
 |>>>>>|  Stop using lorder and ranlib when building libraries
 |>>>>>|
 |>>>>>|  Use of ranlib or lorder is no longer necessary with current linkers
 |>>>>>|  (probably anything newer than ~1990) and ar's ability to create an
 |>>>>> object
 |>>>>>|  index and symbol table in the archive.
 |>>>>>|  Currently the build system uses lorder+tsort to sort the .o files
 |> in
 |>>>>>|  dependency order so that a single-pass linker can use them.
 |> However,
 |>>>>>|  we can use the -s flag to ar to add an index to the .a file which
 |> makes
 |>>>>>|  lorder unnecessary.
 |>>>>>|  Running ar -s is equivalent to running ranlib afterwards, so we can
 |>>>>> also
 |>>>>>|  skip the ranlib invocation.
 |>>>>>
 |>>>>> That ranlib thing yes (for long indeed), but i have vague memories
 |>>>>> that the tsort/lorder ordering was also meant to keep the things
 |>>>>> which heavily interdepend nearby each other.  (Luckily Linux
 |>>>>> always had at least tsort available.)
 |>>>>> This no longer matters for all the platforms FreeBSD supports?
 |>>>>>
 |>>>>
 |>>>> tsort has no notion of how dependent the modules are, just an order
 |> that
 |>>>> allows a single pass through the .a file (otherwise you'd need to list
 |> the
 |>>>> .a file multiple times on the command line absent ranlib). That's the
 |>>>> original purpose of tsort. tsort, lsort, and ranlib all arrived in 7th
 |>>>> edition unix on a PDP-11, where size was more important than proximity
 |> to
 |>>>> locations (modulo overlays, which this doesn't affect at all).
 |>>>>
 |>>>> There were some issues of long vs short jumps on earlier architectures
 |> that
 |>>>> this helped (since you could only jump 16MB, for example). However,
 |> there
 |>>>> were workarounds for this issue on those platforms too. And if you
 |> have a
 |>>>> program that this does make a difference, then you can still use
 |>>>> tsort/lorder. They are still in the system.
 |>>>>
 |>>>> I doubt you could measure a difference here today. I doubt, honestly,
 |> that
 |>>>> anybody will notice at all.
 |>>>
 |>>> The x86 archicture has relative jmps of differning lengths, even in
 |> long mode
 |>>> there is support for rel8 and rel32.
 |>>
 |>> That's irrelevant though for several reasons:
 |>>
 |>> 1. The compiler has already decided on what jump instructions to use
 |> based on
 |>>   the requested code model (unless you're on RISC-V and using GNU bfd ld
 |> as
 |>>   that supports linker relaxations that actually delete instruction
 |> bytes).
 |>>
 |>> 2. The linker is still free to reorder input sections however it likes,
 |> it
 |>>   doesn't have to follow the order of the input files (and the files
 |> within
 |>>   any archive).
 |>
 |> Hm actually that's only true for archives; it needs to respect the \
 |> order of
 |> files on the command line for things like crti.o to work. But regardless,
 |> the
 |> other points (and this one, partially) still hold.
 |>
 |>> 3. If you care about those kinds of optimisations you should use
 |> link-time
 |>>   optimisation which will likely do far more useful things than just
 |> optimise
 |>>   branches, but again isn't constrained by the order of the input files,
 |> it
 |>>   can lay out the code exactly how it wants.
 |>>
 |>> Not to mention that this is just a topological sort, not a clustering
 |> sort.
 |>
 |
 |Yea. I doubt you'd be able to measure a difference on anything in our tree.

Very interesting, thank you all.
Profiling based sort order, impressive even.  I thought more about
cache hotness and, simply, keeping interdependent things together
as such.  But well, caches are so big today, and everything is
dynamically linked, i only jerk a bit due to that runtime cost
myself.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r365836 - head/share/mk

[Steffen Nurpmeso]

Alex Richardson wrote in
 <202009171507.08hf7qns080...@repo.freebsd.org>:
 |Author: arichardson
 |Date: Thu Sep 17 15:07:25 2020
 |New Revision: 365836
 |URL: https://svnweb.freebsd.org/changeset/base/365836
 |
 |Log:
 |  Stop using lorder and ranlib when building libraries
 |  
 |  Use of ranlib or lorder is no longer necessary with current linkers
 |  (probably anything newer than ~1990) and ar's ability to create an object
 |  index and symbol table in the archive.
 |  Currently the build system uses lorder+tsort to sort the .o files in
 |  dependency order so that a single-pass linker can use them. However,
 |  we can use the -s flag to ar to add an index to the .a file which makes
 |  lorder unnecessary.
 |  Running ar -s is equivalent to running ranlib afterwards, so we can also
 |  skip the ranlib invocation.

That ranlib thing yes (for long indeed), but i have vague memories
that the tsort/lorder ordering was also meant to keep the things
which heavily interdepend nearby each other.  (Luckily Linux
always had at least tsort available.)
This no longer matters for all the platforms FreeBSD supports?

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

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

[Steffen Nurpmeso]

Ravi Pokala wrote in
 :
 |-Original Message-
 |From:  on behalf of Mateusz Guzik \
 |
 |Date: 2020-08-10, Monday at 03:40
 |To: , , 
 |Subject: svn commit: r364071 - head/sys/kern
 |
 |Author: mjg
 |Date: Mon Aug 10 10:40:14 2020
 |New Revision: 364071
 |URL: https://svnweb.freebsd.org/changeset/base/364071
 |
 |Log:
 |  cache: strlcpy -> memcpy
 |
 |But why?

Ach, i like it!  I, coming from (basic ->) perl -> java -> C++ ->
C always hated that C string functions which iterate stuff over
and over again, but especially so if working on buffers of which
the length is known.  I mean, you know, if i know i have a NUL
terminated buffer and its length, why in the world should i use
one of those mysterious C string functions?  I know there is one
NUL, it is at LENGTH, dammit!
I like it, several such commits flew by over the last at least
weeks, and i could imagine that in a cache it also matters.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r362246 - head/share/man/man9

[Steffen Nurpmeso]

Hello.

I seem to have nothing else to do but looking at trivial commits.
Sorry for that.

Rick Macklem wrote in
<202006162051.05gkpsyx065...@repo.freebsd.org>:
 |Author: rmacklem
 |Date: Tue Jun 16 20:51:28 2020
 |New Revision: 362246
 |URL: https://svnweb.freebsd.org/changeset/base/362246
 |
 |Log:
 |  Update VFS_CHECKEXP.9 for the argument changes done by r362158.
 ...
 |  This is a content change.
 ...
 |+++ head/share/man/man9/VFS_CHECKEXP.9Tue Jun 16 20:51:28 2020 \
 ...
 |-.Fn VFS_CHECKEXP "struct mount *mp" "struct sockaddr *nam" "int *exflag\
 |sp" "struct ucred **credanonp"
 |+.Fo VFS_CHECKEXP
 |+.Fa "struct mount *mp"
 |+.Fa "struct sockaddr *nam"
 |+.Fa "uint64_t *exflagsp"
 |+.Fa "struct ucred **credanonp"
 |+.Fa "int *numsecflavor"
 |+.Fa "int *secflavors"

.Fo needs .Fc.

 | .Sh DESCRIPTION

Ok .Sh resets it all, but .Fo opens and .Fc closes.
I currently deal with MusicBrainz data (since that single query
alone is not offered via JSON but only via XML, so then all and
only XML, yippieh), and i get for something like this

  not well-formed (invalid token) at line 2, column 2968, byte 3007 at 
/usr/lib/perl5/site_perl/5.28/linux-thread-multi/XML/Parser.pm line 187.

(Caused by a tmux mouse-selection copy and paste problem only,
everything all right.)  I wonder why mandoc lint does not catch
such things.  Don't you have git commit hooks which catch that.
I mean, i do not, but then i am not a professional ^_^

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r362017 - in head/usr.bin/sed: . tests

[Steffen Nurpmeso]

Hey.

Ian Lepore wrote in
:
 |On Thu, 2020-06-11 at 16:29 +0200, Steffen Nurpmeso wrote:
 |> Hello.
 |> 
 |> Mateusz Piotrowski wrote in
 |> <995726df-cb28-c294-09ca-6cca302b2...@freebsd.org>:
 |>|On 6/11/20 12:06 AM, Steffen Nurpmeso wrote:
 |>|> Yuri Pankov wrote in
 |>|> :
 |>|>|Mateusz Piotrowski wrote:
 |>|>|> Author: 0mp (doc,ports committer)
 |>|>|> Date: Wed Jun 10 19:23:58 2020
 |>|>|> New Revision: 362017
 |>|>|> URL: https://svnweb.freebsd.org/changeset/base/362017
 |>|>|> 
 |>|>|> Log:
 |>|>|>Read commands from stdin when -f - is passed to sed(1)
 |>|>  ..
 |>|>|Am I reading it wrong, or is it the same test case added 3 times?
 |>|>
 |>|> It also used "Fl f Cm -" instead of "Fl f Ar -".  Just saying..
 |> 
 |>|Which is correct. "-" is not a variable here. It is a fixed string hence
 |>|the use of Cm.
 |> 
 |> I would rather say no, .Ar is an argument (to the ".Fl"ag f),
 |> whereas .Cm is a command modifier:
 |> 
 |>Command Modifiers
 |>  The command modifier is identical to the '.Fl' (flag) command \
 |>  with the
 |>  exception that the '.Cm' macro does not assert a dash in front \
 |>  of every
 |>  argument.  Traditionally flags are marked by the preceding dash, \
 |>  however,
 |>  some commands or subsets of commands do not use them.  Command \
 |>  modifiers
 |>  may also be specified in conjunction with interactive commands \
 |>  such as
 |>  editor commands.
 |> 
 |
 |Yeah, but...
 |
 |   The '.Fl' macro without any arguments results in a dash representing
 |   stdin/stdout. Note that giving '.Fl' a single dash will result in
 |   two dashes. The '.Fl' macro is parsed and is callable.
 |
 |And that seems to argue that "Fl f Fl" is correct.

This will not result in a well-formed XML document.

I seem to have lost track now.  He wanted to document the typical
"is standard input" argument to the command line option (flag) -f,
didn't he?  If so then "Fl f Ar -" should be the correct way of
documenting this.

Of course - "modifies the command" ("is a command modifier"), heh.
You could also say "Fl f Pa -" if you go that route, because the
argument should be a path, yet it is not in this very special
case, which denotes standard input.  But i would use "Fl f Ar -".

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r362017 - in head/usr.bin/sed: . tests

[Steffen Nurpmeso]

Hello.

Mateusz Piotrowski wrote in
<995726df-cb28-c294-09ca-6cca302b2...@freebsd.org>:
 |On 6/11/20 12:06 AM, Steffen Nurpmeso wrote:
 |> Yuri Pankov wrote in
 |> :
 |>|Mateusz Piotrowski wrote:
 |>|> Author: 0mp (doc,ports committer)
 |>|> Date: Wed Jun 10 19:23:58 2020
 |>|> New Revision: 362017
 |>|> URL: https://svnweb.freebsd.org/changeset/base/362017
 |>|> 
 |>|> Log:
 |>|>Read commands from stdin when -f - is passed to sed(1)
 |>  ..
 |>|Am I reading it wrong, or is it the same test case added 3 times?
 |>
 |> It also used "Fl f Cm -" instead of "Fl f Ar -".  Just saying..

 |Which is correct. "-" is not a variable here. It is a fixed string hence
 |the use of Cm.

I would rather say no, .Ar is an argument (to the ".Fl"ag f),
whereas .Cm is a command modifier:

   Command Modifiers
 The command modifier is identical to the '.Fl' (flag) command with the
 exception that the '.Cm' macro does not assert a dash in front of every
 argument.  Traditionally flags are marked by the preceding dash, however,
 some commands or subsets of commands do not use them.  Command modifiers
 may also be specified in conjunction with interactive commands such as
 editor commands.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r362017 - in head/usr.bin/sed: . tests

[Steffen Nurpmeso]

Yuri Pankov wrote in
:
 |Mateusz Piotrowski wrote:
 |> Author: 0mp (doc,ports committer)
 |> Date: Wed Jun 10 19:23:58 2020
 |> New Revision: 362017
 |> URL: https://svnweb.freebsd.org/changeset/base/362017
 |> 
 |> Log:
 |>Read commands from stdin when -f - is passed to sed(1)
 ..
 |Am I reading it wrong, or is it the same test case added 3 times?

It also used "Fl f Cm -" instead of "Fl f Ar -".  Just saying..

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r358562 - in head: . share/man/man5 share/man/man7 tools/build/options tools/tools/nanobsd/dhcpd tools/tools/nanobsd/embedded usr.bin usr.bin/calendar usr.bin/calendar/calendars usr.bi

[Steffen Nurpmeso]

Hello Gordon.

Gordon Bergling wrote in
:
 |Thanks for the revert. I handcrafted https://reviews.freebsd.org/D23581 \
 | a while ago, and this took me \
 |two days.

This is tremendous!  Your work is exactly what i planned to do
somewhen in the near future!

  The calendar port is a bit out of date and will get some love
  soon.  (I want to merge all calendars from FreeBSD, NetBSD and
  OpenBSD plus some more, but that needs some time.)
  (2020-02-14)

Thanks a lot for that, i will steal it!!
Ciao,

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r358562 - in head: . share/man/man5 share/man/man7 tools/build/options tools/tools/nanobsd/dhcpd tools/tools/nanobsd/embedded usr.bin usr.bin/calendar usr.bin/calendar/calendars usr.bi

[Steffen Nurpmeso]

Conrad Meyer wrote in
<202003030020.0230k9h2002...@repo.freebsd.org>:
 |Author: cem
 |Date: Tue Mar  3 00:20:08 2020
 |New Revision: 358562
 |URL: https://svnweb.freebsd.org/changeset/base/358562
 |
 |Log:
 |  Add extremely useful calendar(1) application to FreeBSD
 |  
 |  It does extremely useful things like execute sendmail and spew dubiously
 |  accurate factoids.
 |  
 |  From the feedback, it seems like it is an essential utility in a \
 |  modern unix
 |  and not at all a useless bikeshed.  How do those Linux people live \
 |  without it?

They install the portable version as a package.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r358153 - head/usr.sbin/services_mkdb

[Steffen Nurpmeso]

Hello.

Pedro Giffuni wrote in
:
 |On 22/02/2020 20:09, Steffen Nurpmeso wrote:
 |> Hey, just so, because i posted to such a thing the last time.
 |>
 |> Pedro Giffuni wrote in
 |> :
 |>|On 22/02/2020 11:18, Florian Smeets wrote:
 |>|> On 20.02.20 04:54, Pedro F. Giffuni wrote:
 |>|>> Author: pfg
 |>|>> Date: Thu Feb 20 03:54:07 2020
 |>|>> New Revision: 358153
 |>|>> URL: https://svnweb.freebsd.org/changeset/base/358153
 |>|>>
 |>|>> Log:
 |>|>>/etc/services: attempt bring the database to this century.
 |>|>>
 |>|>> -smtps 465/tcp#smtp protocol over TLS/SSL (was ssmtp)
 |>|>> -smtps 465/udp#smtp protocol over TLS/SSL (was ssmtp)
 |>|> I'm not sure how removals of services have been handled in the past.
 |>|> This change broke loading of my pf rule set, as I had smtps in there.
 |>|
 |>|Excellent!
 |>|
 |>|Not that the change broke something but that since we had to revert it
 |>|we get a second chance to review such things.
 |>|
 |>|> I'm not saying that this change is wrong, but I think removing entries
 |>|> from services can break all kinds of stuff. Not just firewall rule \
 |>|> sets,
 |>|> also scripts and thinking more about it, it will most certainly also
 |>|> break postfix as it also uses smtps as an alias for port 465 in its
 |>|> master.cnf
 |>|
 |>|According to latest IANA registy:
 |>   ...
 |>
 |>kpasswd   464/udp   # kpasswd (Theodore Ts o)
 |>urd   465/tcp   # URL Rendezvous Directory for SSM \
 |>(Toerless Eckert)
 |>submissions   465/tcp   # Message Submission over TLS protocol \
 |>(IESG, IETF Chair, rfc8314) [2017-12-12]
 |>igmpv3lite465/udp   # IGMP over UDP for SSM (Toerless Eckert)
 |>digital-vrc   466/tcp   # digital-vrc (Peter Higginson)
 |>
 |> Oh yes, they finally managed to overcome the SMTPS problems.
 |> The RFC has a nice reading on that (as i seem to remember), yay IETF.
 |> I am really happy.  (I never understood why POP3S and IMAPS where
 |> done but SMTPS was not.)

 |Hmm .. I quoted the IANA list but I hadn't read the RFC. Interesting but 
 |I don't know if it solves Florian's issue.

It surely will not if he uses smtps not submissions strings.

  ..
 |>|For the time being, we can absolutely keep the legacy value with a
 |>|conflict note. I wish the services list were a bit easier to maintain
 |>|for such situations.
 |>
 |> Doesn't it just search until it finds the string?
 |> Btw. i can only offer the simple awk script that i have for
 |> updating services and protocols again, after the critics last time
 |> i have evolved it from its ArchLinux base, and added a verbose
 |> mode, as you can see above.  (That Theodore Ts'o missspelling is
 |> IANA rooted.)  Whereas it made it more complicated, 139 lines for
 |> download and preparation is not that much.
 |
 |Interesting. There's also
 |
 |https://reviews.freebsd.org/D17115
 |
 |Where I made some comments.
 |
 |Currently services_mkdb doesn't scale (which is why the patch was 
 |reverted), but beyond that the real problem is that we shouldn't just 
 |take the entries blindly. Many people abuse the registry for their 
 |startups and licensing services and then never de-register them.  In the 
 |case of NetBSD's services file, it currently has 21838 lines, which is 
 |bigger that the official IANA file.

Hm.  I track it for some time, and have not found this to be
a problem for my average use case.  And if it changes, then
because the IANA registry has actually changed, because of
requests of those who are responsible for a protocol.  (The entire
unified diff to last year's version including timestamp etc. is
335 lines here, or about three percent of the 11423 lines the file
has and 11395 last year's file had.  Many renames this year.
Likely in the groove and would be more nice if named xy.)

In fact many programs bake their use cases in due to all the mess
(MongoDB service is new this year), on CRUX-Linux, which uses
git(1), for example, /etc/services did not have the git service
until first the FreeBSD file became imported, and then last year
the small awk script.  Worked for years without problems.

I mean, for the cacert repository i have for almost a decade, and
which only generates a single file, but nonetheless, i have a local
additions and removals mechanism.  All plain text, and works with
Unix text tools.  Why FreeBSD needs XML and python and something
out-of-tree, or anything more complicated as

   < ./local.rc sed -E -e '/^#/d' -e '/^[[:space:]]*$/d' |
  while { read file; read url; read finger; }; do
 if [ "${url}" = - ]; then
echo 'local.rc: removing: '"${file}"
sed -i -e '/^'"${finger}&q

Re: svn commit: r358153 - head/usr.sbin/services_mkdb

[Steffen Nurpmeso]

Steffen Nurpmeso wrote in
<20200223010937.ftlhw%stef...@sdaoden.eu>:
  ...
 |Btw. i can only offer the simple awk script that i have for
 ...

(List removes attachments.)

A nice Sunday everybody!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r358153 - head/usr.sbin/services_mkdb

[Steffen Nurpmeso]

Hey, just so, because i posted to such a thing the last time.

Pedro Giffuni wrote in
:
 |On 22/02/2020 11:18, Florian Smeets wrote:
 |> On 20.02.20 04:54, Pedro F. Giffuni wrote:
 |>> Author: pfg
 |>> Date: Thu Feb 20 03:54:07 2020
 |>> New Revision: 358153
 |>> URL: https://svnweb.freebsd.org/changeset/base/358153
 |>>
 |>> Log:
 |>>/etc/services: attempt bring the database to this century.
 |>>
 |>> -smtps 465/tcp#smtp protocol over TLS/SSL (was ssmtp)
 |>> -smtps 465/udp#smtp protocol over TLS/SSL (was ssmtp)
 |> I'm not sure how removals of services have been handled in the past.
 |> This change broke loading of my pf rule set, as I had smtps in there.
 |
 |Excellent!
 |
 |Not that the change broke something but that since we had to revert it 
 |we get a second chance to review such things.
 |
 |> I'm not saying that this change is wrong, but I think removing entries
 |> from services can break all kinds of stuff. Not just firewall rule sets,
 |> also scripts and thinking more about it, it will most certainly also
 |> break postfix as it also uses smtps as an alias for port 465 in its
 |> master.cnf
 |
 |According to latest IANA registy:
 ...

  kpasswd   464/udp   # kpasswd (Theodore Ts o)
  urd   465/tcp   # URL Rendezvous Directory for SSM (Toerless 
Eckert)
  submissions   465/tcp   # Message Submission over TLS protocol (IESG, 
IETF Chair, rfc8314) [2017-12-12]
  igmpv3lite465/udp   # IGMP over UDP for SSM (Toerless Eckert)
  digital-vrc   466/tcp   # digital-vrc (Peter Higginson)

Oh yes, they finally managed to overcome the SMTPS problems.
The RFC has a nice reading on that (as i seem to remember), yay IETF.
I am really happy.  (I never understood why POP3S and IMAPS where
done but SMTPS was not.)

 |Anything that can be done upstream to sort this out?
 |
 |> I guess this needs to be at least mentioned in the release notes, and
 |> maybe smtps kept as an alias, and check all the others that were removed?
 |
 |For the time being, we can absolutely keep the legacy value with a 
 |conflict note. I wish the services list were a bit easier to maintain 
 |for such situations.

Doesn't it just search until it finds the string?
Btw. i can only offer the simple awk script that i have for
updating services and protocols again, after the critics last time
i have evolved it from its ArchLinux base, and added a verbose
mode, as you can see above.  (That Theodore Ts'o missspelling is
IANA rooted.)  Whereas it made it more complicated, 139 lines for
download and preparation is not that much.
Additions could simply be echoed?

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"